Mudança de domínio do blog

Pessoal, para quem acompanhava este blog direto pelo site, informo que estou fazendo uma mudança de servidor, agora este blog não mais estará no domínio WordPress, arranjei um pouco de tempo e instalei em meu próprio domínio (http://refatorandopadroes.jteam.com.br) após apanhar um pouco do PHP =D consegui até personalizá-lo um pouco. Para quem acompanhava pelo feed não tem problema, ele continua o mesmo (obrigado FeedBurner! ^_^)

Quando cansa tentar obedecer a semântica web

Posso dizer que já criei muitas páginas HTML de dar medo, sem o mínimo de obediência aos padrões estabelecidos pela W3C, ou mesmo seguindo a sintaxe correta, mas com tags erradas, semântica incorreta. Aprende-se mais a cada dia e hoje tento fazer o meu melhor em seguir a semântica, eu digo tento, porque os browsers teimam em me desafiar.

Não é novidade que o Internet Explorer é, de longe, o pior caso em seguir padrões web, mas simplesmente não podemos abandoná-lo. Que o digam os meus clientes, que de forma alguma trocam de navegador.

Não sou bom em design, nunca fui, dou minhas patadas, mas para bolar layouts de sites novos eu sempre passo para um outro amigo, também freelancer. Infelizmente ele, embora crie layouts muito bons, não tem experiência em padrões web, sendo assim, cabe a mim adequar o código fonte, e como já disse, faço o melhor que posso. Mas quando o seu layout deve ser flexível e um determinado elemento teima em não se apresentar corretamente em um certo “browser”, é necessário parar para pensar: “sacrifico o layout ou a semântica desse bloco ?”

O tempo urge pelo sacrifício da semântica, os mega indexadores preferem o sacrifício do layout. Eu opto tentar ao máximo ir pela semântica, mas não sou fanático ao ponto de jogar fora o layout só porque um elemento não funciona direito no browser X ou Y. Se o elemento que fugirá da semântica é de mínima importância, não pense duas vezes,  quebre o padrão, mas somente faça isso quando não houver outra alternativa, esgotaram-se mesmo as possibilidades. É fácil seguir a semântica quando sua página é um “linguição fixo”, agora quando os elementos devem ser adequar ao perfil do usuário aí você se complica.

Podem me jogar pedras, mas por favor, o façam também contra o IE. Sempre crio o conteúdo utilizando como navegador o Firefox, e tudo que fiz sempre funcionou corretamente nele. Rezo para que um dia ele chegue à liderança e com grande margem, e somente nesse dia é que eu conseguirei convencer meu cliente a trocar de navegador, antes disso, nós é que temos que ser flexíveis.

Mas lembre-se um pequeno trecho sacrificado que no futuro pode ser corrigido com o uso de melhores navegadores é uma coisa, chutar toda a semântica é bem diferente, por favor nunca façam este último, sigam padrões, ou pelo menos 99,99% deles.

Como a filosofia de convenção ao invés de configuração do Rails enganou um novato

Há cerca de 3 meses resolvi me aventurar no mundo da linguagem Ruby, embora estivesse curioso há um bom tempo, foi mais por necessidade do que curiosidade, e como não poderia deixar de ser, utilizando o framework Rails. Só tenho a dizer o quanto a dupla Ruby+Rails me surpreende a cada dia, mas não é por isso que deixarei de utilizar Java, prefiro trabalhar com ambas as linguagens, escolhendo a que melhor convier ao projeto, prazo, custo e hospedagem, mas esta história fica pra outro post.

Como todo novato, apanhei feio no início, e é claro ainda estou tropeçando, mas o que mais me fez rir foi não ficar atento a filosofia do Rails de “convenção ao invés de configuração”, ou seja, seguir padrões de nomes de métodos, classes, estrutura de diretórios, etc. Há um “jeito” certo de se estruturar o código seguindo esta filosofia, e quando você sai dela é que sua dor de cabeça começa, é normal encontrar pessoas zangadas com erros estranhos que só acontecem por não ter seguido as regras. As pessoas ficam bravas pois estão acostumados a seguir um modo rotineiro de estruturação. Bem estas pessoas que se adaptem às coisas novas. Pessoalmente se um framework segue “convenção ao invés de configuração” já consegue me atrair logo de cara pois eu entendo isso como “me faça ter menos trabalho pra utilizar você”.

O meu erro foi ter “apenas” criado no modelo uma coluna com nome “type”. O que eu não sabia, é que para o Rails, uma coluna “type”, é reservada automaticamente para salvar o class-name do objeto na tabela, para caso você necessitar de um modelo de herança simples. Vamos supor um objeto Cachorro e outro Gato, ambas descendem do objeto Animal, mas há uma única tabela (Animal) para salvar Cachorro e Gato, a coluna “type” seria automaticamente preenchida com o class-name correspondente do objeto, para que ao consultar o registro, o Rails saiba que objeto deve criar. Óbvio que esta não era minha intenção, após ver sucessivas vezes o erro “:in `instance_eval’: compile error” e consultar a documentação, descobri o motivo.

Não posso culpar o Rails, é um padrão dele, assim como outros nomes também são reservados como created_at e id, são os chamados MagicFieldNames. Resumindo: ao trabalhar com “convenção ao invés de configuração” lembrem-se sempre de olhar quais convenções são estas, vai te prevenir muitos erros e com certeza vai aumentar em muito sua produtividade, afinal o padrão está lá pra ser seguido.

Ah sim, caso você realmente precise de uma coluna chamada type para outros fins, basta sobrescrever o seguinte método no modelo:

def self.inheritance_column
“<nome da coluna a ser utilizada ao invés de type>”
end

Pronto, agora o Rails utilizará esta coluna para salvar o class-name e a type fica livre para fazer o que melhor convier, embora eu não recomende fazer isso.

Criando um booleano de três estados

Antes de tudo este post não vai falar sobre física quântica, o objeto Boolean continua sendo aquele já conhecido por nós, mas vou falar sobre um anti-pattern que com certeza fez o Sr. Boole revirar no túmulo e que pessoalmente ainda me causa pesadelos.

Eu estava trabalhando em um módulo de um projeto, a certa altura houve necessidade de se criar uma integração com um outro módulo, nós passaríamos algumas informações, dentre elas indicar ou não se um usuário confirmou uma operação durante o processo, até aí tudo bem, combinamos que para esta confirmação seria passado um Boolean.FALSE ou Boolean.TRUE. Integração implementada e testada.

Após um mês, o mesmo pessoal desta integração me avisa que está tudo errado no conceito da confirmação do usuário, o que outro módulo esperava eram três estados diferentes: se o usuário “disse” NÃO, se o usuário “disse” SIM ou se o usuário não indicou nenhuma das duas opções anteriores… sim eu sei… não fez sentido pra mim também na época, mas acreditem fazia sentido para eles. Mas o problema, é que não houve tempo de opinarmos, o outro lado simplesmente já tinha decidido que seria enviado Boolean.TRUE, Boolean.FALSE ou NULL, caracterizando assim caríssimos, um glorioso mega anti-pattern: um Booleano de três estados. Tentei argumentar para mudarmos para um enum ou pelo menos constantes inteiras, mas não houve acordo, tivemos que aceitar o “monstrinho”, alegaram problemas de tempo para mudanças em vários lugares no módulo, o que já era um sinal de que havia coisas piores.

Lembrem-se, perder um tempo refatorando agora é um tempo ganho no futuro, ganhei várias dores de cabeça por causa desse anti-pattern.

Nem Java suporta métodos gordinhos

Fato interessante ocorreu com uma amiga que estava trabalhando em um JSP enorme, bem que poderia haver menos dados a serem mostrados, mas não sou eu quem decido… enfim… lá pelas tantas, o compilador começou a reclamar de “code too large”, caramba como assim ? Era inserir mais um caracter e dava erro, tirava o caracter e funcionava…

Bom não tem jeito, Google ao resgate… minutos depois problema encontrado e resolvido, o que ocorre é um limitação imposta pelo próprio compilador, um método em Java pode ter um tamanho máximo de 65534 bytes, portanto quando o JSP era convertido em Servlet acabava gerando esse método monstrinho gordinho, mais informações sobre este e outros limites você encontra aqui na especificação da Virtual Machine.

Para resolver o problema foi necessário, adivinhem ? Simmmm, REFATORAR….. basta dividir o JSP em arquivos menores que façam mais sentido e uni-los com <jsp:include>. Para ajudar ainda mais não se esqueça de utilizar padrões web para o HTML gerado, mais tableless, o código fica muito mais enxuto, e quando possível, pense bem antes de criar uma tela com tantos dados, para uma melhor usabilidade.

Claro que, embora seja uma limitação imposta pelo compilador, NUNCA crie um método tão grande, isso vale para qualquer linguagem.

Classloader: como utilizar

É incrível como aprendemos algo novo todo dia, mesma que a lição venha de forma lenta e dolorosa… recentemente, em uma empresa onde presto serviços em Java, tivemos um problema com o DWR (tenho enorme paixão por este componente, o modo como fizeram a ponte entre Java e Javascript chega a ser mágico, é o estado da arte em uso de Javascript, mas isso fica pra outro ‘post’… =D)

Pois bem, o problema foi ocasionado durante testes de migração pra o JBoss 4.x, a inicialização do DWR estava falhando, não conseguia de forma alguma encontrar as classes informadas em seu arquivo de configuração xml, o famigerado NoClassDefFoundError, algo que não apresentava problemas no JBoss 3.x. Após olhar em empacotamento, meta-infs, jars, configurações do JBoss, nada, nenhuma pista, nem o Google ajudou. O jeito foi descer mais fundo, ler o código fonte do DWR. A linha onde o erro ocorre, executa apenas um carregamento de classe:

this.classDefinition = Class.forName(className) ;

A classe é guardada para que possa ser instanciada por reflexão posteriormente, o interessante é que tudo isso ocorre na inicialização do JBoss, depois que a aplicação levanta, tentamos via debugger, executar o mesmo comando e voilá… funcionava perfeitamente… o que raios estava acontecendo ? Não sabíamos….

Bom, não teve jeito, a classe do DWR teve de ser alterada para testar outra possibilidade de carregamento. Com isso trocamos a linha para:

this.classDefinition = Thread.currentThread().getContextClassLoader().loadClass(className);

Linha monstruosa…. mas funcionou!

Boa prática aprendida: o Class.forName() não sobe na hierarquia de ClassLoader, fica apenas no ClassLoader local, enquanto o ClassLoader.loadClass() sim, ou seja, por questão de robustez e boa prática, sempre utilize a segunda forma, para não ficar com cara de “ué”, quando este tipo de problema surgir.

Mas por que no JBoss 3.x funcionava e no 4.x não ? A resposta é que o ClassLoader o 4.x foi reescrito para ficar mais aderente as especificações, com isso o Class.forName() pegou todo mundo desprevinido, houve claras reclamações da comunidade, mas temos que viver com isso…, existem práticas a serem seguidas.

Ainda bem que não tivemos que usar o código alterado do DWR, estávamos na versão 1.1.3, por curiosidade, baixei a versão estável mais recente (1.1.4) e pra minha grata surpresa essa linha já havia sido alterada do mesmo modo que fizemos :D, só fiquei chateado por essa alteração não estar presente no release notes, teria me economizado tempo durante busca por pistas…

Quando uma imagem vale mais que mil palavras

Certa vez, Nelson, um colega de trabalho, me passou pelo MSN um arquivo entitulado “Standards in a Nutshell.pdf”, abri-o, e como de costume para todo o livro que vejo pela primeira vez, tentei ir direto ao índice, nem paro para ver a capa. Qual não foi minha frustração quando vi que o PDF só tinha uma única página.

“Nelson, acho que aconteceu algum problema, o PDF abriu mas só tem uma página aqui!”

Pensei: “Bom enquanto ele não responde vou dar uma olhada na capa”. Pra minha surpresa, ao vislumbrar a imagem abaixo, percebi que nada havia de errado com o arquivo, lá estava tudo o que precisava ser dito, ou no caso mostrado =D, sobre padrões em um página HTML.

Simples assim.

Tudo que eu já havia lido sobre padrões nessa área, tudo o que muitas pessoas de bom senso pregam como ideal, está aí. Ao invés de um calhamaço de 600 páginas, uma imagem que é compreendida em alguns segundos.

Javascript, CSS e HTML separados. Quem dera todos os designers fizessem isso, as vantagens são absurdas: menos consumo de banda, afinal os mesmos arquivos de CSS e Javascript serão usados em todos os outros arquivos HTML, reusabilidade e o principal, um padrão de separação entre o comportamento e apresentação da página, maravilhas das maravilhas para futuras manutenções. Basta apenas ligar os arquivos .css e .js com uma tag no arquivo HTML e pronto.

É claro que não poderia deixar de dar crédito a autora pela obra de arte.

Standards For Life

Preciso criar um cartaz bem grande com isso, talvez alguém olhe e crie juízo. =D

O pior anti-pattern de todos: God object

    Nada melhor, quando aprendendo sobre um assunto novo, do que saber o que NÃO fazer. Anti-pattern (Anti-padrões), nada mais são do que programar contra a reusabilidade e flexibilidade.

Óbvio que não é possível programar com a melhor flexibilidade e reusabilidade, aliás nem devemos tentar, como já disse Tony Hoare: “Premature optimization is the root of all evil” (”Otimização prematura é a raiz de todo mal”). Mas devemos sim estar atentos a código inútil, mal escrito ou ambos. É aí que entra o que considere o pior dos anti-patterns. O God object, o objeto que faz tudo, ele é onisciente, conhece a todos e todos dependem dele, assobia e chupa cana ao mesmo tempo, são classes com milhares de linhas, e o pior de tudo, assim como o próprio Deus, ninguém sabe de onde veio e nem para onde vai, mas com certeza levará todo o sistema junto em colapso.

Muito cuidado com esse tipo de objeto, se você notar que sua classe ou mesmo um único método está fazendo mais do que uma tarefa, pare… reflita… e RE-FA-TO-RE, nunca tenha medo de mexer no que está feito, lembre-se que alguns instantes refatorando lhe trará muitos benefícios no futuro.