Arch Linux Brasil : Perl atualizado para 5.20

Leandro Inácio escreveu:

Perl 5.20, como qualquer outra nova versão do perl, requer que todos os módulos que o código não seja perl puro precisa ser recompilado. Fizemos isto em todos os pacotes em nossos repositórios.

A última grande atualização mostrava uma mensagem de erro quando tentava carregar os módulos compilados com a versão errada, 5.20 parece causar falha de segmentação. Por favor, certifique-se de recompilar todos os módulos e binários padrão instalados com CPN que aponta para libperl.so.

Atenção para o meu post na arch-dev-public para um script que ajuda a identificar estes pacotes.

URL da notícia: https://www.archlinux.org/news/perl-updated-to-520/

Helio Costa - hlegius : Mock elevado à enésima potência

Mocks: mock é um assunto polêmico em Software Testing nos dias atuais. Quase todos defendem o uso, Robert Martin que o diga. Logo, você começa a ler, um passo depois está fazendo seus próprios mocks e gosta do que vê. Num piscar de olhos, está Mockando tudo que pode e fica feliz com isto.

Ver um teste com 3, 4, 5 até 6 mocks pode no começo parecer algo sensacional, mas uma coisa que é necessário aprender sobre Mocks é que assim como seu teste, ele fala. Não uma mutação do say do OS X, mas com sua própria e simples linguagem: em excesso torno-me algo extramemente ruim. É exatamente isso que ele diz aos berros quando ele é super utilizado em um mesmo Test Case.

Pecando pelo excesso

Ao Mockar, esqueça essa frase popular de que é melhor pecar pelo excesso. Overmocking é tão ruim quanto não mockar at all. Se eu tivesse que escolher entre Mockar excessivamente ou não mockar nada, eu optaria pela segunda opção mantendo todas minhas dependências levemente soltas. (assunto para posts futuros!)

Quando você estiver forçado a stubar/mockar muita coisa para que um teste seu possa ficar isolado o suficiente para então testar a funcionabilidade (que você isolou), isso quer dizer simplesmente o seguinte: seu design ficou acoplado e como tal, precisa ser repensado para algo menos atrelado. Deixando suas dependências (outras classes) mais independentes, a quantidade de mocks por teste cairá e seu problema sucumbirá.

O acoplamento é aterrorizante para alguns ou/e em algumas situações, mas eles acontecem quando se perde o controle do que está criando ou quando se modifica o comportamento sem modificar como as coisas se falam. Sabe aquela história de: "ah, modifica isso aqui rapidinho só para X fazer Y." - quando você muda, 99.9% de chances de criar acoplamento e a consequência disso reflete diretamente sobre a quantidade de itens mockados por teste.

Mocks por Teste

Matematicamente dizendo, não há um número exato para mocks por teste (mocks/teste), mas eu tenho meu limite pessoal baseado em nada erro e acerto: 3 mocks/teste para mim é o limite aceitável. Ao ultrapassar isto, automaticamente aquele meu código que o teste exercita cairá na minha Lista de Redesign. Isto forcará a repensar se é caso de refazer ou se é uma exceção. Tudo questão de análise caso a caso. Caso você tenha uma abordagem diferente com seu limite por teste, comente ao final ;)

Mockar apenas o que te pertence

Um ponto defendido por alguns é o de only mock what you own, em outras palavras seria: não mock seu framework; não mock sua API; Mock apenas o que você criou. Aquilo que faz parte do seu domínio. Seu framework é um domínio transversal, ou seja, é um domínio que auxilia você a criar seu próprio domínio. Lembre-se disso!

Com o Rails em particular, eu acabei por várias vezes não seguindo isto. Na verdade, eu não sou muito a favor disto pode me julgar, xingar, etc.. O motivo é simples: o Active Record se mistura de uma forma tão intríseca ao seu domínio, que em alguns momentos é difícil dizer aonde está a linha que separa o framework do seu código. Por este motivo, eu já fiz mock dos finders do ActiveRecord.

O problema de mockar o framework é que você ao fazer esse tipo de maluquisse precisa estar atento é de que ao mocka-lo, você presume como ele irá se comportar dado um certo input porém se por algum motivo sua intuição/palpite estiver errado, seu teste te dará um resultado errado. Com o resultado errado, seu teste passará, mas na hora de rodar o código de produção sem os mocks, o comportamento esperado não acontecerá. O Teste te deixará na mão, por causa do mock e por falha sua.

Mockar o framework é muito perigoso. O teste poderá tornar-se arisco. O true poderá ser false e você precisará lidar com isto.

Concluíndo

Mock é um aliado importantíssimo em Test-First. Sabê-lo utilizá-lo é ainda mais importante.

Helio Costa - hlegius : Definir classes não é programar com orientação a objetos: Ciclo de vida.

Há pouco mais de 2 anos, falei sobre esse tema na PHP Conference Brasil e acho válido revisitá-lo uma vez que muitos desenvolvedores sentem orgulho em dizer que programam orientado a objetos, mas ao fazer uma simples pergunta acabam não sabendo respondê-la:

O que é Orientação a Objetos ?

Alan Kay, criador da linguagem Smalltalk e um dos primeiros defensores da orientação a objetos, a explicou da seguinte forma:

"The big idea is "messaging" (...)

Pronto, fim do post. Obrigado por ler.

Messaging ?

De nada adianta falar sobre Test-First, Princípios de Orientação a Objetos, Mocking, AntiPatterns uma vez que não se conhece o núcleo da Orientação a Objetos.

O grande cerne da questão é justamente a troca de mensagem entre objetos através de seus métodos. É assim que Alan Kay defendeu e é assim que o Smalltalk funciona. Recentemente, alguns desenvolvedores, especialmente em Ruby, têm voltado a reforçar o propósito em OO.

A melhor forma de manter seu código desacoplado e "falante" é forçar os objetos a trocarem mensagens. Lembra do Tell Don't Ask? Pois é, aqui isso é parte chave para atingir-se tal objetivo.

Vou repetir:

• http://c2.com/cgi/wiki?TellDontAsk
• http://pragprog.com/articles/tell-dont-ask
• http://martinfowler.com/bliki/TellDontAsk.html
• Tem a versão do Giovanni Bassi, do .NET Architects também;

Pronto, acho que deu para entender o quão importante é manter no objeto a responsabilidade de manipular os próprios dados (armazenados em vossos atributos).

O Ciclo de Vida de um Objeto

Já parou para pensar em qual seria o ciclo de vida de um objeto?

Bom, inicialmente ele Nasce, depois Cresce, Continua disponível e finalmente Morre.

O nascimento de um objeto

O nascimento do objeto é através de seu construtor. Simples, porém muitas vezes ele acaba ignorado, ainda mais quando vicia-se em utilizar frameworks arquiteturais sem entender o motivos das coisas.

Correto:

Employee.new(name: "Durval", lastname: "da Silva", cpf: "123.123.123-X")

new Employee("Durval", "da Silva", "123.123.123-X")

Incorreto:

durval = Employee.new
durval.name = "durval"
durval.lastname = "da Silva"
durval.cpf = "123.123.123-X"

durval = new Employee();
durval.setName("durval");
durval.setLastname("da Silva");
durval.setCpf("123.123.123-X");

O motivo é simples: o construtor é o contrato que nos diz: "para você obter um novo objeto tipo Employee, você precisa obrigatoriamente me informar: Nome, Sobrenome e CPF, pois caso contrário, você criará um Employee inválido."

E é justamente o que o exemplo incorreto faz: cria um Employee sem dado algum. Quem garante que eu irei chamar setName, setLastname e setCpf depois? Eu posso esquecer. Pode nem ser eu o responsável por utilizá-lo depois. (APIs-like).

Lembre-se o construtor é a certidão de nascimento do objeto. Não tire dele esse direito. Brasil, país rico é país...

Cresce

Aqui temos outros métodos que mudarão o status de nosso objeto ao longo de sua vida. Nem sempre é com setter - outro erro comum daqueles que programam por coincidência. Veja exemplos:

Correto:

employee.exame_admissional = arquivo_pdf_do_exame  # snake case r0cks

employee.setExameAdmissional(arquivoPdfDoExame)

employee.definir_credencial_de_rede(username: "new_username", password: "983hJfh78")

Incorreto:

objeto_credencial = Credencial.new(username: "new_username", password: "9789237498")
employee.credencial = objeto_credencial

objetoCredencial = new Credencial("new_username", "3798472398478234")
employee.setCredencial(objetoCredencial)

Neste caso, o incorreto viola o encapsulamento da Credencial, deixando a cargo do cliente conhecer como a Credencial é criada. Para entender melhor, desenho:

Cliente é toda classe que utiliza outra. Só para deixarmos as coisas claras por aqui.

O problema aí é que no caso o Controller precisa saber como construir Employee e Credencial, além de precisar conhecer como relacioná-las. Um exemplo mais OOP seria:

Agora, o Controller precisa apenas lidar com Employee e este lidará com a Credencial. Em pseudocódigo, ficaria:

# Ruby
class Employee
  # construtor e outros métodos ocultados

  def define_credencial(username: username, password: password)
    @credencial = Credencial.new(username: username, password: password, employee: self)
  end
end

# Java, et al.
class Employee {
    private Credencial credencial;

    public void defineCredencial(String username, String password) {
        credencial = new Credencial(username, password, this);
    }
}

Neste caso, Credencial é um Value Object pertencente ao Employee. Esse tipo de relacionamento é parte do Domain-Driven Design e é chamado de Aggregate Root.

Aggregate root são úteis quando você tem um relacionamento aonde a Parte (Credencial) é totalmente dependente do Todo (Employee). Em outras palavras: a Parte só tem vida quando o Todo tem vida. Não é legal que uma Parte tenha vários Todo(s).

Continuando disponível

Em orientação a objetos, nossa linha de pensamento deveria ser um pouco mais ampla. Ou seja, devemos pensar que uma vez que o objeto é criado (instanciado) ele ficará disponível até que alguém o mate (remova da memória). Enquanto ninguém o remover da memória, ele continuará vivo.

É importante esquecer o meio/tipo de armazenamento aqui. Robert Martin (@unclebob) falou sobre isso na sua must watch palestra na Ruby Midwest 2011 - sério: assista até o fim. Você será outro depois disso ;)

Morre

O objeto é removido através do Garbage Collector, Removido com ORM, etc. Aqui não há novidade mesmo.

1 imagem, 1000 palavras

O meio de vida do objeto (aquele dentro do retângulo) é aonde a maior parte dos objetos estarão. Ao buscar um objeto com um Repository por exemplo, devemos pensar que o objeto estava em memória, já construído e do jeito que o deixamos da última vez que trabalhamos com ele. Ou seja: o Repository não dará new novamente, pois o objeto já existe. Pelo que me lembro, o Doctrine 2 seguia isto: ao recuperar um objeto do Repository o construtor não era chamado novamente - o que é excelente, pois o Ciclo de Vida do Objeto não é quebrado!

Concluíndo?

O tema é extenso assim como Test-First. Conhecer bem o que a Orientação a Objetos reserva e espera de você é pré-requisito para iniciar com Teste de Software em aplicação Orientada a Objeto. Na sequência, continuarei a falar sobre Object Oriented Design para permitir que se veja além ao testar software.

Arch Linux Brasil : screen-4.2.1 também não consegue recuperar instâncias antigas

Leandro Inácio escreveu:

Melhorias do upstream no screen-4.2.1 deixará usuários incapazes de recuperar instâncias antigas criadas com versões 4.2.0 ou mais antigas. Por favor atualizem para screen-4.2.1-2 apenas quando elas forem desnecessárias. Desculpem novamente pelo inconveniente.