Existe vida após o primeiro teste passar?

Conseguiu fazer seu primeiro teste passar. Está orgulhoso de seu novo achievement porém sabe que esse primeiro passo é apenas o início para conseguir mensurar uma evolução no seu processo de desenvolvimento usando Test-first como referência de design de código. Agora, tudo que você precisa é continuar neste ciclo.

Ciclo Test-Driven Development

O ciclo é importante para evitar se atrapalhar e perder o ritmo neste começo. Fato! Mas, ainda mais importante é ter uma ideia clara do que pretende fazer a seguir.

Saindo um pouco de Test-first, uma coisa legal que você pode fazer é ter uma ToDo list. São aquelas coisas simples onde você organiza suas tarefas. Vai de Remember The Milk até um Trello ou Pivotal Tracker . Obviamente cada um deles tem seus pontos de ataque, mas tangenciei o tema justamente para te alertar que uma mente organizada, ajuda e muito você manter um ritmo. Minha técnica é bem simples: ao final do dia, eu vejo meu progresso no software e estimo um novo ponto de parada para o próximo dia. Quando o dia chega, eu tenho em mente que meu objetivo do dia é “Conseguir enviar um Pedido com sucesso”, por exemplo.

Com a organização em dia, você sabe o que atacar agora. Assim sendo, podemos voltar ao Test-first exclusivamente.

Vida após o primeiro teste com Test-first

Qual a próxima feature importante do seu negócio? Veja, entenda como feature requisitos funcionais e não funcionais, ou seja, pode ser algo não necessariamente explicito pelo chefe/cliente, mas algo que você percebeu fazendo seu teste de unidade com Test-Driven Development. Acredite: isso acontece e muito!

Criar cenários sem final feliz é igualmente importante ao cenário feliz. Se você espera que seu código some dois números, o que acontece se você mandar dois null para ele somar? Ele deveria fazer algo? Se é importante que ele seja resiliente e lide com este tipo de coisa, você deve criar um teste de unidade para este cenário também!

É perfeitamente aceitável criar um teste de unidade que dado dois null ele deverá retornar uma exceção (Exception). O anormal, seria você criar um teste de unidade que não espera que uma exceção seja lançada. Neste caso, você deve esperar um valor de retorno ou que um mock seja chamado.

Muito interessante criar testes que exercitam diferentes cenários e configurações de seus inputs. Por exemplo, numa inscrição, você pode simular o comportamento do método que inscreve pessoas, utilizando pessoas cadastradas, pessoas elegíveis à inscrição e pessoas não elegíveis a inscrição. Desta forma, você teria testes assim:

it “fará a inscrição dado um usuário elegível”

it “não fará a inscrição ao receber um usuário expirado”

it “não fará a inscrição ao receber um usuário inelegível”

Na maioria dos casos, você pode perfeitamente possuir mais de um caso de teste para um mesmo requisito funcional que você pegou para fazer.

O código mudará

Acostume-se. Ele mudará! No seu primeiro teste você não tem nada no seu domínio. Após o primeiro teste, novas coisas surgirão. No segundo teste, você acabará mudando código de produção que afeta o primeiro teste. Isto é ruim? Muito pelo contrário: isto é excelente. Significa que você está literalmente Guided by Tests, pois está criando o código necessário para seu teste passar. Está com isso deixando o Test-first guiar seu design de código.

Problemas irão ocorrer. Em problema, o primeiro passo é não seguir adiante. Mantenha-se aonde está, exatamente no teste que você está com dificuldades. Tente entender o que o teste está lhe dizendo. No mês de agosto inteiro, dediquei os posts a tratar os problemas mais comuns ao tentar seguir adiante com TDD. Leia o Prelúdio da série “Rua sem saída” e veja se eu abordei sua dúvida. Isto te ajudará a voltar aos trilhos (Rails ;P) com Test-first.

Concluindo

Organização mental; Seguir passos palpáveis que dão retorno rápido em modificações; Lembrar-se do Red, Green, Refactor; Efetivamente fazer o teste antes do código de produção, pois o teste te auxilia a guiar o design do código; saber “ouvir” o teste; e, o mais importante: não ter medo de mudar seu código de produção devido a um novo teste de unidade são a chaves necessárias para abrir qualquer caminho travado.

Pulando para fora da caixa: a bicicleta como meio de transporte em São Paulo

Desde minha infância, quando eu pedalava tranquilamente pelas ruas dos bairros próximos, eu enxergava tudo aquilo como uma enorme aventura. Aventura não como alguns vêem atualmente pedalar hoje em São Paulo, mas uma aventura no sentido de conhecer novos lugares de uma forma mais plana.

Fora da Caixa

Quando comecei a trabalhar na cidade de São Paulo, comecei a perceber que havia pessoas que utilizavam bicicletas para fazer coisas úteis - Na minha infância, a causa mais nobre era eu ir buscar carne no açougue do bairro para minha mãe, veja só! - Tudo aquilo para mim era visto como impossível, pois ora, bicicleta no meio da rua, vê se pode uma coisa destas!?

Na época, eu até li sobre cicloativismo e tudo mais que acontecia em alguns sites e para ser bem honesto via aquilo com muito ceticismo, pois as ruas estavam cada vez mais violentas e no meu caso, por percorrer grandes quilômetros por dia, não via aquilo como algo viável e cheguei a questionar o uso da bicicleta na rua.

A mudança...

... pra São Paulo deu um novo start sobre o tema na minha cabeça. Obviamente, por ter se passado dois anos, era possível ver mais adultos com propósitos nobres pedalando suas bicicletas pelas ruas, vielas, becos e avenidas da cidade. Isso me fez lembrar da época em que eu utilizava a minha magrela para a Nobris Causa e pude começar a entender o que levara àquelas pessoas a se aventurar pelos caminhos de São Paulo.

Isso me fez lembrar de pessoas que não vão à padaria sem o carro (meu pai é um deles - literalmente) e analisando friamente, não faz sentido algum isso! Do ponto de vista da engenharia, o motor rodava 3 minutos e era desligado. Depois, mais 3 minutos e pronto. Isso é chamado de uso severo do motor, pois você nem consegue curtir um ar quente que vem do motor de tão rápido que era seu uso - pior: eu estava exatamente no mesmo cenário. Mercado? Carro; Padaria? Carro; Hospital? Claro, que de carro; Trabalho? Errr... o carro serve pra isso, oras!

O aplicativo que gerencia o carro era taxativo: média de 76km/dia com o carro incluindo finais de semana/feriados. O que para mim no começo era uma vitória, pois vinha de 115km/dia, passou a ser um tormento. Foi então que tomei a decisão: vou achar um bairro que tenha comércio próximo. Quero um bairro mais de velho - pois vou fazer as coisas a pé. Exatos dois meses depois, me mudei para um bairro plano, de velho que tem no raio de 800 metros: padaria, mercado, mercadinho, feira-livre(s), drogaria(s), brechó, barbeiro, bancos, escola, igreja (quermesse - hmmm!), ponto de ônibus, loja de roupa, loja de chinelo até uma Subway e Lojas Americanas!

A vida saltou de 76km/dia motorizados para: Ops, preciso ligar o motor do carro pois faz uma semana que não ligo ele, pobre coitado!

Na época, estava em homeoffice o que pode ser considerado uma desculpa para isto - até que:

Fim do homeoffice

Dadas minhas constraints (ser perto de casa, flexível, proposta adequada a minha linha de estudo/pesquisa), fechei contrato de trabalho na empresa cuja a sede (e local de trabalho) ficam a 7 km de casa. Perto? Aaaaah, mais ou menos. Meu limite eram 10km pelo menor caminho possível.

Ok, há uma estação de trem aproximadamente 1 km de casa e a empresa fica na mesma linha deste trem 6 estações depois da "minha". Mesmo assim, resolvi colocar meu segundo plano em ação: bicicleta como meio de transporte.

Bicicleteiro, bicicletista, bicicleísta, ...

Ciclista! Escolhi uma bicicleta urbana e confortável - como não andava há pelo menos 10 anos e o trajeto seguro de bicicleta são de aproximadamente 11 km, optei por uma elétrica (pedal assistido) - que em miúdos, pode aliviar a força necessária no pedal - mas não anda sozinha, afinal é uma bicicleta e não uma moto. O pode é simplesmente por haver a opção de pedalar com isso desativado.

Ciclocomputador

Um dos momentos que praticamente me escorreu uma lágrima foi quando comprei meu Ciclocomputador. CARA, era meu sonho ter um daqueles trequinhos que marcava sua velocidade. Eu nunca tive grana pra comprar um, mas vivia babando neles nas bicicletarias do bairro. Depois de mais de uma década, consegui ter um treco que marca a velocidade da bicicleta. Pode parecer tolo, mas toda minha infância veio em mente naquele momento.

Eu li e reli sobre regras de trânsito específicas para bicicletas, direitos, deveres e como elevar minha segurança na via. Item aliás muitíssimo importante antes de pedalar pelas ruas de uma cidade movimentada. Entender que andar na contra-mão é perigoso e que andar na calçada é totalmente errado por colocar em risco pedestres também fazem parte, por exemplo.

Mesmo sendo este meu sexto mês utilizando bicicleta como meio de transporte - não só para o trabalho, mas no geral, ainda assim consigo afirmar que a vida como ciclista em São Paulo tem melhorado desde quando comecei. Talvez pelas recentes ações da prefeitura e mais ainda pelo aumento do uso da bicicleta nas ruas. Vejo diariamente gente de todas idades/estilos pedalando bicicletas das mais variadas formas, tamanhos e modelos. Uma coisa que eu percebi de imediato foi meu humor. Depois, a percepção das coisas ao meu redor. Comecei a valorizar mais o comércio local e o de rua, evitando sair de uma caixa para entrar em outra (Shopping Center). Quando uso o carro, tornei-me mais paciente e gentil com todos no trânsito - não me tornei um semi-deus, apenas bem mais tranquilo. Falando em carro, utilizo-o quase toda semana quando vou ao interior do estado assistir aulas. Com isto, pude também perceber que andar de carro não é isso que as pessoas vivem aqui na cidade, mas sim, percorrer quase 300 km livre de trânsito curtindo paisagens diferentes, morros e colinas é tão proveitoso quanto andar 10 km de bicicleta na cidade.

Hater de carro ?

Muito pelo contrário. Quem me conhece, sabe o quanto gosto de engenharia, especialmente aeronáutica e automobilística. Leio, pesquiso e pratico coisas referentes à direção defensiva, mecânica e engenharia automobilística. Tenho minhas preferências é claro - o que aconteceu foi apenas uma nova percepção sobre o quão mal utilizamos o carro seguida pela minha decisão de utilizá-lo para uma causa nobre e não para ir e vir do trabalho/padaria.

É possível mesmo ?

Entenda que nada será mais cômodo do que sair da casa, ir na garagem coberta, entrar no carro, ligar o ar-condicionado, apertar dois ou três pedais, sair através de seu portão automático até a garagem do prédio onde trabalha, descer protegido do sol/chuva pela laje do estacionamento e entrar no lugar. Na bicicleta/transporte público/etc você não terá isso como vantagem. Os valores destes modais de transporte são outros e você precisa ter isso bem claro em tua mente se pretende adotá-la para algumas de suas tarefas.

Já fui e voltei para o trabalho de bicicleta debaixo de uma chuva torrencial. O meu tempo de ida e volta foi exatamente o mesmo de um dia sem chuva ou/e véspera de feriado ou/e invasão alienígena. Enquanto pessoas reclamavam de estar há 2 horas no trânsito eu já estava em casa, escrevendo isto :P

O tempo é um dos fatores. O outro é não se preocupar. A facilidade de locomover-se com a bicicleta é enorme, pois trata-se de um item leve, pequeno e dobrável (se a tua dobrar) - dá para estacionar em qualquer lugar que tenha onde prender e resolvido. Custo de manutenção é baixíssimo e você mesmo consegue aprender a resolver os itens mais corriqueiros.

Por fim, é importante lembrar que a bicicleta não é a solução de todos os problemas da galáxia. Ela é uma das opções viáveis para aqueles que estivem dispostos a utilizá-la. A grande mudança dar-se-á com a melhoria e expansão do transporte público, principalmente sob trilhos.

Continuará

Não vou me alongar com dicas, segurança, itens, modelos de bicicleta, etc, pois existem sites excelentes sobre o tema na internet a fora. Vou abordar sobre a ótica da vida sob duas rodas na cidade de São Paulo. Aos poucos, vou citar problemas/soluções que encontrei no caminho para tornar a locomoção ainda mais agradável e tranquila.

Anda de bicicleta em sua cidade? Comentaí ;)

Gunga no 5º SLOW FILME

Está tudo pronto para a quinta edição do SLOW FILME – FESTIVAL INTERNACIONAL DE CINEMA, ALIMENTAÇÃO E CULTURA LOCAL, que acontece de 11 a 14 de setembro, em Pirenópolis, Goiás. Único em seu perfil no Brasil e pioneiro na América Latina, SLOW FILME vem com uma programação que vai proporcionar o contato do público com títulos que foram destaques em festivais como Berlim e NYC Food Festival e que chegam ao País pela primeira vez.

O 5º SLOW FILME quer reforçar ainda mais o compromisso com a temática da sustentabilidade, da qualidade artística e do ineditismo com uma programação para mexer com todos os sentidos. Serão quatro dias de muito cinema, palestras, degustações e contatos com produtores que trabalham segundo os conceitos do respeito ao meio ambiente e à produção local. SLOW FILME tem curadoria de Sérgio Moriconi , patrocínio da PETROBRAS e copatrocínio do SEBRAE. Realização: Objeto Sim Projetos Culturais. Apoio: Embaixada da França e Embaixada do Canadá, Slow Food Pirenópolis, Instituto Cervantes e Grupo de Trabalho do Slow Food Brasil sobre queijos artesanais de leite cru. Também tem o apoio da Prefeitura de Pirenópolis e da Secretaria Municipal de Cultura.

Na noite de abertura, 11 de setembro, o público poderá assistir a três curtas-metragens nacionais: ‘Baru – a castanha do cerrado’ (com um registro da colheita e quebra da castanha do cerrado, dirigido por Diego Mendonça e Farid Abdelnour), ‘Você sabe de onde vêm seus alimentos’ (do Coletivo Aura, que apresenta a famosa Feira dos Agricultores de Porto Alegre) e ‘Coragem é um dom’ (dirigido por Tiago Carvalho, sobre o trabalho de um casal de agricultores do sertão baiano). A sessão começa às 19 horas, no Cine Pireneus.

fonte: objetosim.com.br

Girassol Filmes

A Girassol Filmes é uma produtora cinematográfica que atua no Distrito Federal desde 2007. Trabalha em criações de cinema experimental, independente e documental.

Para a Girassol Filmes criamos seu novo Logotipo e o projeto gráfico de seu ultimo filme “Raul no Além”.

 

girassol_filmes_90dpi AVATAR imagemweb_raulencarte lancamentobannerface

Como deixar de correr o risco de usar material autoral

Ultimamente eu acabei voltando a mexer com o Worldpress, por conta do site da Loja Maçônica da qual faço parte (Gonçalves Lêdo), um problema que eu estava enfrentando era conseguir imagens (vetorizadas, no meu caso) para poder gerar outras imagens. Depois de caçar exaustivamente na internet, lembrei do básico: Site da Creative Commons. A Creative [&hellip

Rua sem saída: não consigo criar meu próximo teste - Parte IV

Seguindo para o último post da série, vou abordar o décimo item da lista inicial. Antes de continuar, veja os primeiros posts da série:

Pro tip: Lembrando que o prelúdio contém tópicos e dicas gerais que servirão para praticamente todos os itens abordados ;)

Demorei tanto pensando numa solução que acabou desistindo e criando o código sem teste. O código de produção funciona (você o testou manualmente), porém ainda não sabe como escreverá (e se) o teste que o validará

WOW! Poderia me estender e enunciar os problemas que isto te causará - isso seria um sermão chato, então sem delongas vou citar apenas um bom motivo pelo qual isto é ruim:

Você precisará testar essa rotina manualmente TODA vez em que mudar o código de QUALQUER PARTE do software

Holy moly! Isso realmente é um bom motivo, concorda? No passado, a cada novo deploy o time precisava testar manualmente todo o site - veja bem: todo o site. A cada deploy então, ficava mais complicado, pois tinha mais coisas a testar. Os bugs não chegaram a ser recorrentes, mas sempre acontecia de uma feature dada como ok quebrar devido a um side-effect maluco.

Vim

Aconteceu uma vez d'eu ver um software em produção não Test-Driven rodando. O cenário era muito crítico. Vários bugs recorrentes, horas para achar e resolver um bug sem quebrar o outro lado, etc. Eu simplesmente peguei do zero e criei uma versão test-driven. Eu não sabia das implementações (pois não participei da implementação original), logo não fui infectado pelas más decisões (de design). Comecei o software seguindo Clean Architecture citado pelo Unclebob. Ou seja: nada de persistência; nada de web-tier; nada de nada. Literalmente fui no meu ~/coding/ e rodei um mkdir: mkdir ~/coding/new-project-api. Depois criei um esqueleto de diretórios ultra simples: mkdir ~/coding/new-project-api/tests e mkdir ~/coding/new-project-api/src/$DOMAIN_MODULE.

Disso, abri um arquivo de teste novo dentro de /tests/$DOMAIN_MODULE/ e criei minha primeira especificação com Teste de Unidade. Para os demais, fui perguntando para os outros devs que tinham trabalhado no projeto inicial, perguntando sobre as features do projeto. Fiz minha versão do software, focando totalmente na arquitetura e design. Depois que tinha várias features prontas e funcionando, adicionei um ODM (Object Document Mapper) com MongoDB e simplesmente nada mudou no meu código e aquelas regras de negócio começaram a salvar árvores no Mongo de forma natural e desacoplada. Somente no final eu pensei em adicionar um web-tier para responder as requisições do HTTP Server. AH mas e a integração com o aplicativo mobile? Eles precisam sabers dos endpoints e o que virá; AH, mas e o frontend; AH, mas e meu chefe; Ah, mas e o cliente. Cada caso é um caso diferente, mas posso afirmar que no meu caso tive que lidar com tudo isso e foi bem tranquilo (após resistências de todos os lados). Acho que o pessoal tem medo de mudança, não sei. As dicas sobre isso ficarão para posts futuros - mas se você estiver em encrenca por causa disto, get in touch!

Ok, mas como escrever o teste que validará o que eu fiz? Há pessoas que fazem teste depois. Eu não sou fã disso, me acustomei com o classical TDD como chamam - mas em todo caso se você tiver experiência com Test-first e souber o que está fazendo, não terá grandes problemas em implementar seu teste. Em qualquer outro caso:

  • Como você testa manualmente?

Ignore as interações com interface e outros datasources. Feito isso, você tem praticamente seu teste de unidade mental. Basta passar para teste de unidade não se esquecendo de que mock/stub é seu amigo!

  • Pensei no item 1. mas testar está complicado.

Talvez você tenha acoplado demais sua implementação e aí o teste está te avisando disto. Recomendo ler o Prelúdio da série. Lá tem ideias gerais para quaisquer uma das 10 situações descritas aqui.

  • Meu software é um algoritmo.

Realmente. TDD não vai te ajudar muito. Se você está criando um algoritmo para resolver um problema, TDD não te ajudará em nada. Agora, se este algoritmo está inserido dentro de um Domain Model, Test-first + Test Unit te ajudará a deixar este algoritmo isolado e respondendo apenas por si só.

  • Estava testando uma integração com Paypal, Google APIs, etc.

A depender do que estava fazendo, Test-first para conseguir conectar numa API e resgatar dados simplesmente com o objetivo de sentir a API, não faz qualquer sentido. Novamente TDD é ferramenta de design de software e não de validação/verificação.

Em resumo: fazer um teste de uma parte do software depois é basicamente engenharia reversa sem os relacionamentos entre objetos/métodos. Lembre-se que isto pode custar caro uma vez que seu design sem o teste pode ter ficado horrível e o teste (de|in)testável.

Concluindo

Por fim, esta série chega assim ao seu término. Espero que tenha ajudado alguém a sair de uma rua sem saída ou no bom português, uma encrenca com test-first. Mudança de paradigma ou modo de codificar não é trivial, mas você estando disposto, é possível obter excelentes resultados a curto prazo.

Lembre-se: a curva de aprendizado e prática com Test-first é de pelo menos seis rápidos meses. Isto me lembra quando comecei a usar o Vim para codificar: enquanto eu não larguei mão dos outros editores, não consegui aprender direito a ferramenta.

Faltou alguma Rua sem Saída que gostaria que eu comentasse? Avisa aí ;)

Dúvidas, desesperos, e bênçãos via comentários nos tópicos ou como sempre, via e-mail.

Reorganização dos pacotes VIM

Leandro Inácio escreveu:

A suite de pacotes VIM foi reorganizada para fornecer o melhor dos recursos avançados no pacote padrão do vim, e para dividir as versões CLI e GUI; os novos pacotes são:

  • vim-minimal: idêntico ao pacote anterior do vim
  • vim: agora inclui todos os recursos do gvim que inclui interpretadores python, lua e ruby, sem suporte a GTK/X
  • vim-python3: a mesma informação mencionada acima para gvim-python3
  • gvim: continua o mesmo
  • gvim-python3: continua o mesmo
  • vim-runtime: continua o mesmo

URL da notícia: https://www.archlinux.org/news/reorganization-of-vim-packages/

Rua sem saída: não consigo criar meu próximo teste - Parte III

Continuando o assunto como criar meu próximo teste, irei abordar os três tópicos seguintes do segundo post da série. Recomendo que os leiam em ordem:

Para continuar, os tópicos 7 e 8 contêm muitas similaridades:

  • Tenho um mock que retorna um outro objeto que precisa também de ser configurado com mock. Parece um mock-de-mock.
  • Vou precisar instanciar vários objetos nesta nova feature.

Para ambos os casos, o problema parece emergir do simples fato de que seu alvo de teste (a classe e behavior testados) está com uma implementação acoplada a outras partes do sistema. Mas, o que isso quer dizer realmente?

Confira se o método testado está:

  • Fazendo mais de uma coisa. Aqui, você pode ser menos flexível para melhor entendimento, por exemplo:

Você criar o seguinte caso de teste: "O usuário conseguirá logar, dado Login e Senha válidos". Daí, você tenta seguir com o seguinte código de produção:

  class User

    def autentica(login)
      if login.username.empty? && login.password.empty?
        raise InvalidArgumentError
      end

      # continua com o login
    end
  end

  ## nosso login ali de cima
  class UserLogin
    def username
    end

    def password
    end
  end

Pode parecer bobagem aqui, mas o método #autentica está fazendo mais de uma coisa: ele está validando input e efetuando autenticação. No seu teste, você precisaria passar um stub de UserLogin e precisaria configurar #username e #password somente para conseguir passar da parte de validação.

Este exemplo é minimalista justamente para evidenciar que casos mais complexos do mesmo problema fará com que você tenha que fazer mock de mock ou ficar instanciando/configurando um monte de objeto somente para fazer uma simples regra de negócio funcionar como deveria. Qual a solução? Vejamos:

Extrair a verificação de input do #autentica seria uma ótima. Quem sabe delegar a responsabilidade da ação para o objeto que o mereça, resolva o problema, não é mesmo? Lembra do Tell don't ask ? Veja-o em prática:

class User

  def autentica(login)
    if login.valid?
    end
  end
end

class UserLogin

  def username
  end

  def password
  end

  def valid?
    !username.empty? && !password.empty?
  end
end

Tudo que precisamos fazer agora é configurar no seu stub que o método #valid? deve ser true. Com uma linha de configuração no teste você consegue focar no que realmente importa: fazer a regra de negócio funcionar.

Estou criando o código de produção e meu método alvo do teste está imenso ou/e cheio de chamadas à métodos privados da própria classe

Dr. Erskine

"Imenso" é subjetivo. Não deve-se encanar com a quantidade de linhas de um teste, mas sim com sua anatomia. Se ele estiver sem repetição e na ordem: input de dados, executa o método em teste, analisa resultados - seu teste estará bem.

O problema com método privado é antigo. Há aqueles que odeiam método privados e do outro lado, aqueles que usam pra tudo. Ambos estão pegando pesado ao meu ver. O método não público precisa ser bem pensado. Como você viu acima, nem sempre a responsabilidade para uma dada atividade na classe pertence à classe que você imaginou. Escalando isso para um sistema, você terá sim muitos métodos privados mal planejados. Como disse, Dr. Erskine em Captain America: The First Avenger:

O soro potencializa o que há dentro da pessoa. O bom torna-se ótimo e o mal torna-se horrível.

Aplicando uma regex s/soro/teste/ e s/pessoa/classe/, teremos uma definição hipster sobre o que é Test-Driven Development.

O TDD nestes casos, irá gritar para você de que há um problema de design ocorrendo em suas classes - e com o auxílio do teste, você consegue sair desta situação. Agora, resolver o problema é com você e seu toolbelt. Dicas:

  1. Tell Don't Ask. Como você viu acima.
  2. Extrair método privado(s) para Classe. Veja se faz sentido.
  3. Injeção de Dependência (via setter ou construtor).

Por fim, caso não tenha lido o post anterior da série, recomendo que o leia, pois há alguns detalhes adicionais aos tópicos discutidos aqui.

To be continued.

Continuação em: Parte 4 - Tópico 10 e conclusão

Recuperando arquivos em HD formatado!

Pessoal achei esse vídeo muito bacana, após passar por uma situação um tanto quanto complicada:

Parece que ajudou bastante gente e que realmente funciona!

 


Testando Contribuições ao Mind Bending

Quando anunciei que o blog estava aberto a contribuições por meio de pull-requests no GitHub, eu ainda não havia concluído a documentação sobre como realizar testes e previsões. Sim o Hack ‘n’ Cast estava tomando muito tempo!

Mind Bending Blog

Bem, agora está tudo documentado e utilizando o Pelican 3.4 (sua versão mais recente). Boa parte deste processo está documentado aqui

Testando Contribuições ao Mind Bending é um artigo original de Mind Bending