01 outubro, 2014

Eu, meu carro e o pavão


Ha a natureza!
Eu gosto da natureza. Cuido pra não jogar coisas por aí, não deixo luz acesa, separo o lixo orgânico do inorgânico, desligo a torneira quando estou escovando os dentes e por aí vai ... E de tempos em tempos tento entrar em contato mais próximo dela também. Faço trilhas a pé e de bicicleta, vou correr nos parques, viajo pra acampar e aceito convites pra ir visitar fazendas. O problema é que a recíproca não é verdadeira. A natureza não gosta de mim. Sempre dá alguma merda e eu volto da minha incursão no mundo natural pior do que entrei. Vou citar alguns exemplos.
                              
- Ainda criança, menino moleque, fui a uma fazenda com meus pais. Brincadeira vai, brincadeira vem e quando volto pra casa percebo que minha perna está com uma marca que parece uma picada de mosquito, só que mais feio e dolorido. O tempo passa e aquela picada cresce feliz e faceira transformando-se em  um furúnculo gigante que não me permitia andar. Lembro que minha mãe até me levou em uma benzedeira que, na sua sabedoria de curandeira, receitou passar uma pasta de farinha com outra coisa que não me lembro o que é (a curandeira morreu uma semana depois disso - creepy!!!). Quando estourou, parecia um vulcão em erupção com toda sorte de nojeiras saindo. Entrei em desespero e por sorte meu irmão estava lá e calmamente (sério, meu irmão é calmo pra essas coisas e além disso a natureza é melhor com ele, mas depois eu conto) limpou tudo com algodão.


Olha meu amiguinho aí.
                                     
- Outra vez estava indo para a base aérea visitar umas pessoas com minha mãe e meu irmão. Fomos de ônibus que nos deixou alguns quarteirões antes. Era legal esses passeios em pessoas que moravam em casa porque nós morávamos em prédio e queríamos aproveitar ao máximo. Nesse curto caminho entre onde saltamos do ônibus e o portão da base, vimos um pé de goiaba. Não lembro de quem foi a ideia, mas entramos no quintal pra subir no pé e pegar algumas. Fui lá pegar e as melhores estavam em um galho meio fino pra ir andando em cima dele. Então eu me pendurei com as pernas e as mãos e fui me arrastando. No meio do caminho percebi uns zunidos. Eu não sei como mas não vi uma colmeia de marimbondos que saíram par ver o que estava acontecendo e ferrar com minha vida. Quando as picadas começaram eu me larguei lá de cima e caí de costas no chão.


Hahaha, esse se ferrou mais que eu.
                                          
 E sem falar de todas as vezes que ao menos um mosquito me ferroa e minha mão incha e vira um pão francês.

  Bom, mas o caso que quero contar é bem mais recente. Há umas semanas atrás fui em um balneário curtir um sol, piscina e .... a natureza. O lugar é bacana, tem lagos, criação de porcos, tanques com tartarugas e uma comida ótima. Passado um tempo que cheguei, um amigo foi lá me pegar para irmos em um campeonato de motocross que estava rolando ali perto.  Quando saí para ir para o carro dele percebi que havia um pavão perto do meu carro. Achei legal ver o bicho por ali e fui assistir o campeonato. Depois de uma hora mais ou menos, voltamos e adivinhem, o pavão ainda estava rondando meu carro. Aí achei estranho e cheguei perto pra dar uma olhada. Foi então que entendi o que estava acontecendo. Ele, o pavão, estava vendo seu reflexo no para-choque do carro e, com todo o seu cérebro de dois centímetros, teve como reação bicar o outro pavão. E fez isso por mais de uma hora. Pronto, a natureza atacava mais uma vez.


Olha o estrago.



Eis o culpado. E foda-se que é bonito.
Quando vi nem fiquei muito irritado. Passei pela entrada e só comentei com o dono do local "Preciso falar com você depois.". Acho que ele já estava sacando o que era o assunto porque quando entrei na piscina tinha umas pessoas comentando que um pavão tinha acabado com o para-choque de um carro.

No fim da darde quando estava indo com o dono ver meu carro ele estava por lá de novo. Pra ele ver que eu não estava tão calmo assim não, taquei uma pedra. Ele pagou a pintura.






24 setembro, 2014

Resenha - No Limite do Amanhã


Ontem assisti finalmente o "No Limite do Amanhã" e, acreditem, a crítica estava certa, é um puta filme bom pra caceta. Na história a Terra foi invadida por uns alienígenas disformes, cheios de tentáculos e que ficam girando tipo o Taz e, ao contrário da maioria das outras invasões alienígenas que a Terra já sofreu, esses E.T.s não têm um poder infinito e vão  dominar o planeta em três dias. Eles começam o ataque pela Europa e demoram anos pra conquistar alguns países. Técnica de guerrilha mesmo, tipo um Vietnã só que agora no mundo todo. O Tom Cruise (Bill Cage) é um major covardão do exército americano que trabalha com a publicidade do exército. Publicitário porque antes da invasão ele tinha uma empresa de publicidade e covardão porque logo no início ele é convocado por um general para registrar a invasão que vai ocorrer no dia seguinte e que é a grande promessa de vitória e ele diz que não quer ir.









 - Eu não sou soldado general. (e o general insiste)
 - É por isso que você vai pra lá com outros 1000 que são. Vai ser tranquilo rapá. (e o major continua)
 - Eu agradeço a honra mas vou ter que recusar. (e o general pensa: Covarde fdp.)
 - Não é uma oferta, é uma ordem.
 - Bom general, do mesmo jeito que eu fiz a publicidade positiva pra conseguir arrebanhar esse monte de besta que se alistou pra lutar contra esses polvos-gigantes-demônios-da-tasmânia, quando essa guerra terminar eu posso fazer sua caveira como o responsável pela morte do monte de besta. (já traduzido as entrelinhas)
 - Ok, você não vai registrar nada. (o general fala isso com um sorrisinho maléfico)


                                      

   Quando o Tom Cruise sai da sala, o general  manda prender. Ele foge e acaba recebendo um tiro de uma arma de choque bem no meio das fuças. Quando acorda ele já foi rebaixado pra soldado, e vai ter que lutar na guerra junto com o pelotão nove. Quem o recebe na base é o sumido do Bill Paxton que vai explicar o que está acontecendo, apresentar o pelotão nove e dar uma treinada pra tocar o pau no dia seguinte. Nessa hora que vê que não vai ter pra onde correr o Tom Cruise já está se borrando todo. 

  Até aqui é só firula pra dar o enredo do filme. O melhor vem agora. Na manhã seguinte, tipo um dia D já que a luta é em uma praia na França e os terráqueos estão crentes que vão vencer, dá tudo errado. Os aliens tão esperando eles e vai acontecendo um massacre. O Tom Cruise tá com uma armadura que não sabe usar e fica cambaleando pra lá e pra cá, desviando dos destroços. Quando ele consegue ativar a metralhadora da armadura ele, ao mesmo tempo que morre, mata um alien Alfa, que é mais poderoso que os outros, e o sangue desse  alien cai em cima dele.

Nessa hora o filme volta pro momento em que ele acorda do choque, na base, e começa tudo de novo. O Bill Paxton aparece, fala as mesmas coisas, e o Tom Cruise vai aos poucos entendendo a merda que aconteceu. Como agora ele sabe que vão perder a guerra, fica desesperado pra contar mas, é claro, ninguém acredita. Depois de umas vinte vezes (e isso não é nada porque até o filme terminar ele morre e volta umas 1000 vezes) que ele morre e volta ele tem a ideia de ir contar o que tá acontecendo pra Xena do lugar. É a lindinha da Emily Blunt (que eu vi pela primeira vez no O Diabo Veste Prada) (Rita Vrataski) que tem todo um status de mega guerreira porque já tinha conseguido matar um caralhão de alienígenas e usa uma espada gigante pra isso. Quando ele chega pra ela com a história ela já tem noção do que está acontecendo e dá um alívio.

Xena falsa
Xena verdadeira

Daí ele propõe o mais óbvio e o que facilitaria a vida de todo mundo. Vamos procurar o general e refazer toda a estratégia. Zzzzuuuummmm errado!! Ela conta que o que está acontecendo com ele já aconteceu com ela e que quando ela tentou contar quiseram interná-la. Acontece que ela perdeu o dom de "reiniciar o dia" porque em um dos dias que voltou não morreu e recebeu uma transfusão de sangue. Daí ela leva ele pra ir ver um cientista fudido que fica meio que escondido em uma salinha e que ninguém sabe que ele é cientista.

Cientista maluco
                                     
Eles contam que em breve ele vai começar a ter visões porque o alien mestre está tentando localizá-lo e essas visões vai revelar onde ele está. Então, basta matar o alien mestre que todos os outros perecerão. Logo ele tem a visão e o objetivo passa a ser chegar até uma represa que fica em uma montanha.

E a aflição começa. Como eles não podem contar pra ninguém o que tá acontecendo e que eles têm a chave pra salvar o mundo e era só confiarem neles porque eles sabiam o que estava acontecendo, eles decidiram ir andando da praia até a represa (que fica na montanha). Só que eles não conseguem andar cem metros na praia antes de morrer. E só pra lembrar, o Tom Cruise mal sabe usar a armadura. Daí uns 30 minutos do filme é o Tom Cruise treinando usar a armadura e eles tentando dar mais que 100 passos. Mas não é chato não. Várias vezes durante o treino ele se arrebenta todo, tipo quebra uma perna ou a coluna, e é legal ver ela dando um tiro na cabeça dele pra "reiniciar o dia". Nesse meio tempo também rola de leve uma paquerinha.


Até que o Tom Cruise consegue chegar na tal represa e surpresa, o alien mestre não está lá. Era uma armação dos sacripantas que implantaram uma visão falsa. De volta pra prancheta. Eles voltam pra ver o cientista e esse fala que tem um dispositivo que conecta as ondas mentais de um alien com o do alien mestre e daí é possível descobrir sua localização. Só que o dispositivo está no cofre na sala do general punheta que não acredita neles.


General chupeta
 Depois de voltar sei lá quantas vezes, eles conseguem fazer o general abrir o cofre e dar o dispositivo. Veja bem, bastava o general dar um voto de confiança e pensar "Ei, a Terra foi invadida por aliens, que loucura mais pode acontecer. Vou acreditar nesse doido e mandar um aviãozinho com uma bomba no lugar onde ele indicar. Vai que né?!". Mas não, o general dá o dispositivo mas manda prendê-los. Eles fogem e durante a fuga o Tom Cruise "pluga" o disposivo nele, se conecta com o alien mestre e descobre onde ele realmente está. Mas a fuga dá merda, eles são capturados e o Tom Cruise recebe uma transfusão. Pronto, acabou a parada de "deu errado tentamos de novo amanhã". Agora é tudo ou nada.

Eles fogem do hospital militar e decidem que vão sozinhos matar o monstro que está em baixo do Luvre, em Paris. Eles convencem o pelotão 9 a ajudar, roubam uma nave, voam até Paris (eles estão ali do lado, em Londres), todo mundo morre menos o Tom Cruise que consegue chegar perto do monstro e detonar várias granadas. Um pouco antes de morrer, já que estava muito ferido, o sangue do alien mestre  banha o corpo do Tom Cruise que, adivinhem .... reinicia o dia mais uma vez.


O filme é bom. Só pecou pelo argumento fraco de que "ninguém vai acreditar na gente".




22 março, 2013

Mozart : Violin Concerto No. 3 (Hilary Hahn) 03





http://hilaryhahn.com/

http://pt.wikipedia.org/wiki/Hilary_Hahn#cite_note-13

Ela escreve e divulga fotos das viagens que faz para suas apresentações em http://hilaryhahn.com/category/postcards-from-the-road/


20 março, 2013

Resumo Effective Java - Parte 3 (Classes e Interfaces)

Capítulo 4 – Classes e Interfaces

Item 13 – Minimize a acessibilidade de classes e seus membros
Item 14 – Em classes públicas, utilize métodos de acesso, não campos públicos

Item 15 – Minimize a mutabilidade

·         Sempre que possível, crie classes imutáveis (não possuem métodos mutators (setters), todos os campos são private, marcar os campos como final, a classe não pode ser estendida, etc). Caso existam operações sobre seus atributos, retorne cópias da classe com os novos valores e não modifique o estado interno.
·         Pode-se disponibilizar fabricas estáticas (Item 1) e prover cache de instancias que já foram criadas. Todos os wrapper de primitivos funcionam dessa forma.

OBS:  Observe que, ser imutável não implica automaticamente que a classe é um singleton.  Uma classe imutável pode ter várias instancias com valores diferentes na memória. Diferente do singleton onde só existe uma instância da classe em memória e seu estado interno não muda na criação.  A abordagem de criar uma fábrica estática pode ser utilizada em ambas as soluções. No singleton por motivos óbvios, e nas classes imutáveis para fazer um controle mais refinado das instancias que serão retornadas.

·         Concluindo, resista à tentação de escrever um método set para cada get criado. Classes devem ser imutáveis a não ser que exista uma boa razão para ser diferente disso.

Item 16 – Utilize composição ao invés da herança

Herança viola o encapsulamento. Subclasses dependem de detalhes de implementação de suas superclasses e assim são suscetíveis às mudanças que podem ocorrer nestas. Vejamos um exemplo

// Broken - Inappropriate use of inheritance!

public class InstrumentedHashSet extends HashSet {

// The number of attempted element insertions
private int addCount = 0;

public InstrumentedHashSet() {}

public InstrumentedHashSet(int initCap, float loadFactor) {
  super(initCap, loadFactor);
}

@Override public boolean add(E e) {
  addCount++;
  return super.add(e);
}

@Override public boolean addAll(Collection c) {
  addCount += c.size();
  return super.addAll(c);  // Na implementação original o addAll utiliza outro método publico 
                                                   // da classe, o add. Quando super.addAll é chamado vai executar o  
                                                   // add. Por conta do polimorfismo, o add sobrescrito aqui é que será 
                       // chamado e incrementará o addCount duas vezes.

}

public int getAddCount() {
 return addCount;
}

}

Perceba como o problema é sutil. Perceba também o efeito do polimorfismo! Mesmo chamando super.addAll quando esse método executar vai chamar o add sobrescrito pela classe InstrumentedHashSet. O fato do método addAll original utilizar um outro método publico (ou protegido) da classe é um fator de fragilização da implementação. Deveria estar bem documentado e quem fosse
·         estender a classe HashSet tem a obrigação de levar em consideração. Mas não se cobre tanto. A API do Java tinha e ainda tem diversas classes com inúmeros problemas de projeto.
·         Novos métodos podem ser acrescentados na superclasse e isso também pode quebrar o funcionamento da subclasse.
·         Um bom substituto na maior parte dos casos onde herança pode ser aplicada é a utilização do Decorator Pattern.

Item 17 – Projete e documente para herança ou então proíba

Herança é segura quando utilizada em classes internas da API, sobre o controle da mesma equipe. Se deixar uma classe da API passível de extensão deve-se tomar algumas precauções.
Uma classe projetada para ser estendida deve documentar com precisão detalhes de implementação de seus métodos públicos e protegidos. Mais precisamente, deve documentar quando ela mesma fizer uso de seus próprios métodos. A documentação deve incluir quais métodos utiliza, em qual sequencia e como o resultado de cada invocação afeta o próximo processamento. Esta documentação aparece por padrão iniciando pela frase “Esta implementação ...”.
Uma classe mais segura para extensão nunca invoca algum método passível de sobreescrita (que é a fonte de todo mal).

public class Super {

// Broken - constructor invokes an overridable method

private int array[];

public Super() {
overrideMe();
}

public void overrideMe() {

  array = {1,2,3,4};  //O array nunca sera inicializado quando a classe Sub for instanciada. O 
                                      //polimorfismo faz com que o método chamado seja o overrideMe 
                                             //sobrescrito.

}



 
}//fim da classe Super

public final class Sub extends Super {

private final Date date;

Sub() {
date = new Date(); //Quando a classe Sub é instanciada, primeiramente o constructor de Super é 
                                     // chamado. Este por sua vez chama o método overrideMe sobrescrito na    
                                     // classe Sub, o qual depende da inicialização de date que ainda não ocorreu.

}

// Overriding method invoked by superclass constructor
@Override public void overrideMe() {
System.out.println(date);

}

} //fim da classe Sub

Item 18 – Prefira interfaces a classes abstratas

Há duas maneiras de se definir um tipo abstrato de dado em Java: com classes abstratas ou através de interfaces. As principais diferenças são:

  • ·         Interface não admite implementar algum dos métodos declarados, uma classe abstrata sim.
  • ·         Para definir um tipo usando classe abstrata é preciso fazer uso de herança, enquanto que com interfaces basta implementar todos os métodos do contrato.

  • ·         Como Java admite apenas herança simples, o uso de classes abstratas para definir tipos fica seriamente comprometido.
  • ·         Classes podem ser facilmente refatoradas para implementar uma interface, basta acrescentar o implements e implementar os métodos adicionais. Classes abstratas geram um efeito colateral muito maior, forçando todos os descendentes estender a nova classe abstrata, sendo isso apropriado ou não para eles.
  • ·         Interfaces podem ser usadas para criar misturas de comportamentos não necessariamente relacionados. Comparable é um tipo que gera esse efeito. O tipo primário de uma classe pode não ter nada a ver com o fato dela poder ser comparada com outros objetos mutualmente equivalentes.  Uma interface permite ir adicionando comportamentos desejáveis sem ferir a coesão. Com a herança simples isso não pode ser feito com o uso de classes abstratas.
  • ·        Criar hierarquias de tipos através de herança é arriscado pois é uma decisão muito forte que vai restringir seu projeto para sempre. Isso na maioria das vezes é ruim porque, em geral, você não tem todas as informações sobre como uma classe vai evoluir e nem quais serão todas as necessidades dos usuários num futuro próximo. Na maioria das vezes, criar hierarquias mais flexíveis através de interfaces é a melhor solução.

Apesar de interfaces não permitirem a implementação de métodos, isso não impossibilita prover assistência aos programadores. Você pode combinar as virtudes das interfaces e classes abstratas para criar classes abstratas com esqueletos de implementação para cada interface não trivial que você pretende exportar. A API de Collections utiliza extensivamente esse recurso através de suas implementações padrão de AbstractCollection, AbstractList, AbstractSet e AbstractMap.

// Skeletal Implementation
public abstract class AbstractMapEntry  implements Map.Entry {




 
 // Primitive operations
  public abstract K getKey();
  public abstract V getValue();

  // Entries in modifiable maps must override this method
  public V setValue(V value) {
    throw new UnsupportedOperationException();
  }

  // Implements the general contract of Map.Entry.equals
  @Override public boolean equals(Object o) {
    if (o == this)
      return true;
    if (! (o instanceof Map.Entry))
      return false;
    Map.Entry arg = (Map.Entry) o;
    return equals(getKey(), arg.getKey()) && equals(getValue(), arg.getValue());
  }

  private static boolean equals(Object o1, Object o2) {
    return o1 == null ? o2 == null : o1.equals(o2);
  }

  // Implements the general contract of Map.Entry.hashCode
  @Override public int hashCode() {
     return hashCode(getKey()) ^ hashCode(getValue());
  }

  private static int hashCode(Object obj) {
    return obj == null ? 0 : obj.hashCode();
  }
}

A grande vantagem dessa abordagem é que ela provê a assistência das classes abstratas sem impor as restrições de quando se define um tipo somente através destas. Para muitos implementadores da interface a escolhe óbvia é estender a classe esqueleto, porém isso é estritamente opcional. Se uma classe não pode estender a implementação esqueleto, ainda poderá implementar a interface e delegar a execução de seus métodos para uma instância privada de uma classe interna que estende da classe abstrata esqueleto (semelhante ao que foi feito no item 16).

Para concluir, projete com cuidado suas interfaces. Uma vez que esta for disponibilizada, é quase impossível alterá-la. Você tem que fazer certo da primeira vez. Acrescentar um método tardiamente irá quebrar qualquer código que faça uso da interface. Ter vários programadores na definição das interfaces é uma boa estratégia.

Item 19 – Use interfaces apenas para definir tipos

Não usar interfaces como um container para acomodar constantes.

// Constant interface antipattern - do not use!
public interface PhysicalConstants {

// Avogadro's number (1/mol)
static final double AVOGADROS_NUMBER = 6.02214199e23;
// Boltzmann constant (J/K)
static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
// Mass of the electron (kg)
static final double ELECTRON_MASS = 9.10938188e-31;
}

Esse é um exemplo de mal uso de interfaces

Item 20 – Prefira hierarquia de classes a usar flags

É comum encontrarmos implementações inexperientes onde o comportamento de uma classe é regido pelo valor de uma flag. Essa flag geralmente é passada como parâmetro no construtor e vai decidir o comportamento da classe dentro de seus métodos. Os métodos terão comandos if ou switch em cada um dos valores possíveis que a flag pode assumir.
Esse tipo de artifício é uma forma muito pobre de simular hierarquia de classes, um dos principais conceitos da orientação a objetos.

Item 21 – Use function objects para representar estratégias

·         Algumas linguagens provêm maneiras para referenciar funções. Isso é útil, por exemplo, para implementar o design pattern Strategy. Um método pode receber um ponteiro para uma função a qual será chamada para executar alguma estratégia específica. Uma classe que realiza ordenação poderia ser implementada dessa forma, recebendo como parâmetro uma função com a implementação da estratégia de comparação adequada.

·         Como Java não possui ponteiros, o padrão Strategy pode ser implementado declarando-se uma interface para representar a estratégia e uma classe que implementa esta interface para cada estratégia concreta que exista. Essa classe terá apenas um método e nenhum estado e é conhecida como um Function Object. No exemplo do comparator (acima), uma interface definirá o método compare e para cada estratégia concreta que exista haverá uma implementação dessa interface. Quando essa implementação concreta é utilizada apenas uma vez, usualmente é definida como classe anônima. Quando houver mais de uma utilização, poderá ser uma variável estática privada exportada por um campo public static final cujo tipo é a interface da estratégia.  

Item 22 – Favoreça o uso de classes internas estáticas

Existem 4 tipos de classes internas (nested): classes estáticas, não estáticas, anônimas e classes locais.

·         Classes estáticas: se a classe interna não precisa fazer nenhuma referência à sua classe encapsuladora, então você deve fazê-la estática. Isso evita que uma referência extra à classe encapsuladora seja criada e gerenciada pelo gc. Um exemplo seria uma classe enum que descreve as operações suportadas por uma calculadora. A classe de enum  Operation poderia ser criada e ser pública e estática na classe Calculator. Clientes da classe Calculator poderiam referenciar as operações usando nomes como Calculator.Operations.PLUS.

·         Classes não estáticas: cada classe interna não estática possui uma referência implícita à sua classe encapsuladora e assim pode chamar os métodos de instância ou usar o this. Abaixo segue um exemplo de seu uso:

// Typical use of a nonstatic member class

public class MySet extends AbstractSet {
... // Bulk of the class omitted

public Iterator iterator() {
return new MyIterator();
}

/*

Uma classe utilitaria que implementa um iterador para os elementos da classe principal. Como precisará acessar os dados dessa classe principal, foi feita não estática.
*/
private class MyIterator implements Iterator { 
...
}
}

·         Classes anônimas: são úteis para a criação de function objetcs (item 21).
·         Classes locais: é a menos utilizada. Pode ser declarada da mesma maneira que variáveis locais.