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

Ser livre não custa nada, é de graça

Olá piratas da internet, tudo bom com vocês?

O post de hoje é sobre essa mudança, radical para alguns, de utilização de programas. Como eu falei no post anterior existem ferramentas que você pode usar sem pagar nada e pode também fugir da obsolescência programada que alguns fabricantes de software fazem.

A principal mudança é o Sistema Operacional, porque no mundo GNU/Linux o que não falta é opção para se instalar em sua máquina. Uma coisa bastante comum que observo em iniciantes é informar o seu hardware e perguntar qual a melhor opção para instalar em sua máquina e se EU uso arch linux, ubuntu ou debian vou acabar falando o que uso, por questões de facilidades pessoal ou afinidade e isso é um ponto negativo. Negativo mandar uma pessoa usar uma distribuição GNU/Linux? Calma que explico :).

Um novato ou usuário recente no mundo GNU/Linux geralmente é direcionado através de pessoas “experientes” e costumam fazer, instalar e testar coisas que outras pessoas as indicam sem ter conhecimento do que se trata e/ou conhecimento das filosofias que as distribuições possuem e acabam tendo dificuldades no inicio de sua caminhada no mundo GNU/Linux. A minha indicação é fornecer links ou explicar o motivo de está indicando a distribuição X e apresentar detalhes de como é o funcionamento da mesma e não fala uma resposta simples achando e/ou querendo que o usuário entenda perfeitamente o que está falando, pois se você o direcionar de forma correta ele não somente se consolida na utilização do Gnu/Linux como também pode convidar outras pessoas para usarem.

Eu não irei entrar em muitos detalhes de como é o funcionamento das ferramentas senão o texto será muito longo e cansativo de se ler, irei comentar ferramentas nas quais você pode ter um sistema funcional e fazer o que um usuário comum costumava fazer em seu sistema que provavelmente era pirata.

Uma das principais desculpas, reclamações e piadinhas de pessoas que não migram para o GNU/Linux por muito anos foi por causa dos jogos. E mesmo com a Steam com um catalogo de mais de 500 jogos algumas pessoas desinformadas insistem em falar que o GNU/Linux não é uma plataforma de jogos. As Steam Machines rodam exclusivamente GNU/Linux e mesmo assim existem pessoas que insistem que a única plataforma para jogo no PC é Windows.

Uma outra dependência e um dos softwares mais pirateadas que já vi é a plataforma de escritório da Microsoft. Escutamos desde sempre que é a melhor plataforma para se digitar texto, fazer planilhas e apresentações e por conta disso acabamos replicando isso sem ao menos saber que existe uma alternativa livre e gratuita. Estou falando do Libreoffice uma plataforma completa, gratuita e superior com relação a sua principal concorrente. As pessoas não costumam usam pelo simples fatos de estarem acostumadas com o pacote office e por conta disso algumas até pirateiam através do PlayonLinux o software proprietário no GNU/Linux. Você tem uma alternativa que não irá gastar nada e insiste em piratear mesmo assim? É hora de mudar, e mudar para melhor.

Navegador indico o Firefox, pois eu duvido que você consiga utilizar o Internet Explore com 20 abas abertas sem travar todo o seu computador. O firefox é gratuito, livre e tem desempenho superior ao navegador padrão do sistema proprietário. Para assistir vídeos temos o vlc um player de música/vídeo que simplesmente toca absolutamente tudo sem grandes problemas.

Para leitura de e-mail temos o excelente e gratuito ThunderBird, desta forma você não tem a necessidade de está sempre abrindo seu navegador para verificar se tem novos e-mails. Para armazenamento na nuvem você pode criar e disponibilizar um servidor usando o Owncloud e não ficar dependente de serviços como Dropbox, OneDrive e etc.

Para gravação de CD/DVD você pode utilizar o Brasero ou K3b para gravar suas mídias ou seus backups sem a necessidade de fazer a compra do software para tal. Para fazer buscar e evitar o rastreamento temos o duckduckgo que é um excelente buscador. Caso tenha alguma dúvida na utilização da sua distribuição ou queira conversar com pessoas que utilizam a mesma distribuição que você temos a Freenode que é uma rede IRC que hospeda a maioria dos canais de distribuição e projetos open-source. Não tem existe a necessidade de utilizar software trial no GNU/Linux, para isso basta usar o pidgin, BitlBee.

Viu como tem alternativas?! Agora só depende de você fazer as mudanças e ser uma pessoa livre, poder instalar, copiar esses softwares em quantos computadores quiser sem se preocupar com chaves, atualizações e pirataria.

Ser livre não custa nada, só depende de você.


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

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:

Estou querendo testar um método privado

Quem nunca não é mesmo? Tudo pode começar com uma inocente vontade de verificar apenas um método privado em apenas uma classe do teu software. Após pesquisar, você concluí: ah, se a linguagem de programação X permite que eu modifique a visibilidade do método para public via reflexão (parte da metaprogramação) é porque isso é bom. Será ?

O primeiro ponto a se analisar é relembrar o que não é Test-Driven Development - spoiler: não é sobre testar se o software não tem bugs. Com a mente fresca, pode-se perceber que se TDD é uma prática de design de código que tem por objetivo guiar seu design baseando-se nos requisitos funcionais do software, por si só, TDD é contra teste de método privado.

Definição método privado por Sandi Metz: métodos privados são métodos unstable da sua API. Entende-se aqui por API todo e qualquer método público de quaisquer objetos. Os métodos privados contêm o necessário para auxiliar métodos de negócio a realizarem suas atividades e por si só, não desempenham quaisquer atividades de valor ao software.

Então porquê quero testar meu método privado? Por causa de uma má definição do design da classe ou feature que você está implementando. A dica chave aqui é repensar nas suas atribuições, ou seja, será que esse método na verdade não deveria ser uma nova classe? Extração em classe aqui geralmente ocorre, então se está travado nisso, pare e repense o design do código que entorna isso.

Quer ver como isso acontece e você nem percebe? Assista essa apresentação de Michael Feathers:

The Deep Synergy Between Testability and Good Design from Tim Yann on Vimeo.

Não consigo isolar a feature que vou criar. Os objetos que irão interagir com ela são complexos para mockar

Situação básica onde você se empolga codificando e quando vai ver virou Big Ball of Mud. Pode ser também que você ficou no deixa disso e não fez Test-First.

Nota para os deixa disso: não estou afirmando que Test-First é a salvação do mundo e que a paz será atingida quando todos o fizerem - meu alerta sobre Test-First é aquele aviso que seu pai/mãe te deu quando você tentou apertar um parafuso do tipo philips com uma chave de fenda, e ignorando-o(a) você seguiu. Foi doloroso, demorado e ficou mal apertado, não foi?

Parafuso philips

Geralmente, você faz mocks utilizando doubles ao invés de instanciar objetos reais para interagir com seu objeto alvo do teste. Se no teste você precisa que seu double chame um método que chame outro para no fim retornar algo, você simplesmente pode fazer seu double retornar o valor esperado do método que seu objeto em teste precisa e pronto, correto?

O problema escala quando você tem objetos métodos que não podem ser mockados. Por que isso acontece? Bem, quando você não injeta suas dependências. Veja só:

class DeixaDisso
    def tdd_eh_mimimi(params)
        Paypal::RestAPI.perform("/paymenow", params)
    end
end

Como é que você testa o DeixaDisso#tdd_eh_mimimi se ao testar isso ele chamará de verdade o Paypal::RestAPI.perform?

Supondo que o código acima seja uma abstração aceitável, o ideal a fazer é extrair o Paypal::RestAPI e torná-lo injetável via método, por exemplo:

class DeixaDisso
    def tdd_eh_mimimi(params, paypal_api: Paypal::RestAPI)
        paypal_api.perform("/paymenow", params)
    end
end

Com isso, no teste você pode passar um double para que responderá ao método perform e você pode fazer o mock dele criando a seguinte expectativa: __espero que seja chamado o método perform com os parametros: /paymenow e params uma vez.

Pronto. Isso é um teste de unidade baseado em expectativa muito útil e simples quando as dependências são injetáveis.

Houve uma vez que eu trabalhei com um framework PHP chamado Phalcon Framework. Quando fui fazer uns testes que envolvia Controllers, etc., descobri que ele disponibilizava os "Serviços" via di que na verdade era um container de injeção de dependência. Para chamar o serviço 'paypal' por exemplo, eu poderia fazer assim:

class FoobarController {

    public function indexAction() {
        $this->di->getService('paypal') # Objeto Paypal
    }
}

Do ponto de vista do Mr. M isso é fantástico, pois você magicamente tem acesso ao $this->di que te lista todos os serviços registrados. Mas... como testar isto sem cair na real implementação dos serviços? A mesma ideia funcionava para os parametros de POST/PUT. Vinha magicamente e não injetado. Essa filosofia seguia também para os Models e ORM.

Não consigo verificar se um evento/callback do framework que estou usando foi chamado

Ora, como teste de unidade testa a unidade de uma funcionabilidade do software, deixar que o callback/evento seja chamado tornaria o teste um teste de integração, concorda?

Buscando evitar que este callback seja chamado de verdade no teste, a melhor solução é verificar se ele foi chamado dado uma condição. Em miúdos, criar uma expectativa em um mock. Como callbacks diferentes podem e são implementados de formas diferentes, não há um recipe mágico aqui, apenas a dica de que devemos garantir que ele é invocado utilizando da técnica de setar a expectativa no mock (como no item acima eu mencionei). Alguns frameworks fornecem assertions expecificos para você testar a chamada a callbaks. Por exemplo, o Rails te permite testar se um e-mail foi enviado sem enviá-lo de facto. Isso permite que você crie testes isolados para estas condições de negócio sem seguir para os mocks.

Por fim e não menos importante, você pode criar um spy no teste que te ajudará a verificar se o estado de um objeto muda após a chamada do callback. O RSpec tem assertion baseado em evento/mudança.

expect {subject}.to change {subject.will_change_x_to_y}.from(x).to(y)

To be continued.

Continuação em: Parte 3 - Tópicos 7, 8 e 9