Da série "Notas mentais": Pessoas

Elas são como livros, só mais inconstantes...

Da série "Notas mentais": Livros

1 - Nunca acredite piamente em um livro. Exceto pela matemática (e mesmo alguns desses), o resto são apenas opiniões e hipóteses. 2 - Nunca duvide demais de um livro. Mesmo em um livro totalmente errado, algumas idéias podem estar certas. (A idéia que um relógio quebrado ainda está certo duas vezes ao dia) 3 - Consolide sua opinião frequentemente, a maior parte do que é certo hoje se torna errado cedo ou tarde, basta dar tempo o suficiente. Pode me chamar de "descrente", se é que isso tem a ver com "crer" :D

Candidatos a idiomas no Java

Apesar de focar muito em Ruby, é o Java quem paga o pão nosso de cada dia. E apesar de eu ter algumas encrespadas com a linguagem, ela é muito competente no que faz. Um pouco travada, talvez, mas ninguém é perfeito :) O interessante é que depois de um tempo, vamos pegando alguns "idiomas", ou seja, mini-padrões que vivem se repetindo. Acho que já li esses dois em algum lugar (muito provável), mas como estou usando eles com muita frequência, gostaria de deixá-los registrados:

---

Idioma: Parâmetros Opcionais Explícitos Problema: Você tem um método quem tem parâmetros opcionais. Frequentemente, a opção não passada é "null" ou tem um valor padrão bem definido. Solução: Crie um método para cada configuração de parâmetros que você tenha e faça os com menos parâmetros chamarem os de mais parâmetros. Apenas o método com mais parâmetros tem a lógica. Reasoning: Sempre usar um único método pode ser um problema se na maior parte das vezes o valor passado é o mesmo. Se você quiser alterar o "padrão", tem que caçar em todo o código. Por outro lado, travar um valor fixo faz você ter que alterar o código se quiser algo ligeiramente diferente. Oferecendo um bom padrão e , ao mesmo tempo, flexibilidade, resolve os dois usos e o custo é baixo. Exemplo:

public Autocomplete ( String className, Object parameter, int maxSize,
 String highlightTemplate ) {
    try {
        this.klass = Class.forName ( className + "Option" );
        this.parameter = parameter;
        this.maxSize = maxSize;
        this.highlightTemplate = highlightTemplate;
        initialize ();
    } catch ( ClassNotFoundException e ) {
        throw new RuntimeException ( "Class not found for \"" + className + "\"", e );
    }
}

public Autocomplete ( String className, Object parameter, int maxSize ) {
    this ( className, parameter, maxSize, "$1" );
}

public Autocomplete ( String className, Object parameter ) {
    this ( className, parameter, 8 );
}

Parece que dá um pouco de trabalho (e até dá), mas é uma maneira muito clara de você passar a idéia de ter parâmetros opcionais, e depois que você acostuma, é completamente trivial alterar os valores padrão. Como experiência própria, só procure evitar "explodir" o número de métodos, procure só fazer os métodos mais usados como padrão e usar a versão "expandida" para flexibilidade total. ---- Idioma: Parâmetros Nomeados Problema: Você tem uma classe que precisa de muitos parâmetros (principalmente opcionais) para ser configurada. Solução: Para cada parâmetro, crie um método "set" que retorna o próprio objeto, assim, você pode encadear os métodos ("method chaining") em um única chamada. Reasoning: Criar construtores com muitos parâmetros torna a classe difícil de usar, e forçar um série de métodos "set" repetindo o mesmo objeto torna o código chato de digitar e às vezes pouco óbvio de ser lido. Exemplo: (Tirado da biblioteca JDOM)

new Element("book").setAttribute ( "id", "1" ).setText("Java Idioms");

O equivalente sem o idioma seria:

Element element = new Element("book")
element.setAttribute ( "id", "1" )
element.setText("Java Idioms");

---

Bom, é isso. Nenhuma invenção nova, só catalogando idiomas que vivo esbarrando e acho legais :)

Estaticamente trabalhoso

Tava observando um amigo meu trabalhar em um framework ontem e percebi umas coisas interessantes. O processo foi mais ou menos assim: O framework era em Java e ele precisava pegar uns registros no banco de dados pra montar uma combo. O framework tinha sido criado em cima do Hibernate e já cuidava de toda parte xarope de sessions e afins. Pra pegar os dados ele criou um Criteria e passou pro framework. Como não havia um DAO para aquele objeto, ele precisou criá-lo, declarar a coisa no Spring e montar o método que buscava o DAO de lá (tá acompanhando? Se perdeu? Inda não acabou). Para preservar a tipagem estática e encapsular as chamadas nas camadas corretas, ele ainda teve que fazer mais três ou quatro declarações de métodos onde a única diferença era o tipo da variável. Fiquei observando e percebi que a única coisa que realmente havia mudado era o Criteria, o resto, todo o resto incluindo o DAO, só foi feito para preservar a tipagem estática e "isolar" as camadas (isso mesmo, "isolar" entre aspas. Tenho ressalvas com isso, mas é papo pra outro post). Não acho tipagem estática ruim e não estou pregando contra divisão de software em camadas, mas fiquei me perguntando o quão longe a gente vai e o quanto a gente complica as coisas onde não há necessidade real. Nesse exemplo não havia. Um simples hql "select x from Classe as x" enviado para um DAO genérico resolveria de sobra. Será que a gente não anda inventando mais coisa do que seria necessário só por questões de "assim o desenvolvedor idiota não vai usar errado" e "assim fica mais flexível"? Precisamos de verdade dessa proteção e dessa "flexibilidade"? O tempo passa, vou ficando mais cético. Só queria saber se pra bem ou pra mal.

E o que deu o SunTechDays

No fim das contas, as palestras estavam todas atrasadas mais de hora e a que eu queria assistir ficou muito tarde. Poisé, fica pro próximo ano... O que valeu mesmo foi ver um carinha dançando pra ganhar uma jaqueta (mó legal a jaqueta). O cara literalmente "se desdobrou", só quem estava lá pra entender. Nunca ri tanto!

Ronie no SunTechDays

(essa porcaria de computador do evento nao estah com os acentos configurados... jah viu como vai sair o post) Depois de todo esse tempo mexendo com Java, resolvi vir a um SunTechDays pra "tirar a virgindade..." Vim soh hoje de manha (dia 20) e pulei o dia 19. Evento bem organizado, tudo muito bonito (sem brincadeira, eh bonito mesmo!). Fui experimentar a palestra do Bruno Souza... ai... ai..., mesma pagacao de pau de sempre, tive que sair logo, antes que ele conseguisse me convencer de que Java era a primeira maravilha do universo e, se Deus usasse Java, o Big Bang teria sido open-source e que eu conseguiria fazer ele no meu celular... Mas o cara eh o "Javaman", entao tah certo. De resto, soh estou esperando, espero que a palestra sobre Scripts rodando na VM seja boa. Pena nao poder ficar o evento todo...

Grandes decepções

Eu estava comentando com uns colegas sobre "grandes idéias brochantes", ou seja, idéias que inicialmente pareciam muito boas, mas que depois descobrimos alternativas melhores, ou descobrimos que não eram lá tão boas assim. [AVISO! O conteúdo a seguir é de alta octanagem e pode causar flame wars ao menor contato com trolls e outros cabeçudos de plantão. Lembre-se que essas opiniões são baseadas na minha experiência pessoal. Sua opinião pode ser diversa e sua experiência pode ser outra, por isso, se quiser dizer que estou errado e sou um idiota, seja no mínimo educado, pra não passar por troll. (E se me ofender, vou aí chutar sua bunda!)] Vou colocar meus 2 centavos de "grandes idéias brochantes" que aconteceram comigo: Brochante 1: RUP Em idos de 1998, quando descobri RUP, achei que era "O" processo. Que a coisa era a solução definitiva para os problemas de projetos de software mal feitos. Comecei a estudar com afinco, e pensei "Nossa, quanta coisa! Mas um bom processo deve ter definição pra TUDO, então tá certo." Depois, tive que fazer um projeto que usávamos um pouco de RUP. No início achei que tínhamos problemas porque estávamos usando pouca coisa, aí aumentamos nossa "aderência" ao RUP. Resultado: tempo gasto com documentação, menos desenvolvimento, documentos desincronizados, mais tempo com documentação, menos desenvolvimento... e no final, ainda muitos bugs e nenhuma estimativa confiável. Fiquei meio com um pé atrás, será que eu tinha errado? Primeira experiência com a coisa, acho que não tinha usado certo. Aí conheci XP. Primeiro projeto besta que apareceu, experimentei. Ótimos resultados. Apareceu um projeto grande, experimentamos XP. A cada prática que colocávamos do XP, melhoravam os resultados. Conclusão: brochei do RUP. Brochante 2: SOAP A primeira vez que vi, achei que web services com soap eram a melhor invenção desde o pão fatiado. Ainda mais a integração que ele tinha com a plataforma .NET, super simples e fácil. Um pouco mais tarde, descobri que o negócio era meio complicado, já que, fora do .NET, mexer com SOAP era um pesadelo (era o tempo do Apache-SOAP ainda, nem existia o Axis). Daí, tive que fazer integração com alguns clientes que estavam usando simples "XML Vai, XML Vem" (protocolo "XV2") com posts e gets. Foi simples, fácil e muito rápido. Pronto, brochou geral. Hoje minha mente buzina "muita solução pra pouco problema" toda vez que penso em SOAP. E olha que isso foi antes d'eu conhecer RESTful Web Services. Brochante 3: Aspectos Quando conheci aspectos, achei a coisa mais poderosa do mundo. Simples, não intrusivo e resolvia grandes problemas. Comecei a estudar. Até ajudei um colega a fazer um chat P2P de brincadeira em que a encriptação das mensagens era feita por aspecto. Colocava aspectos, pum, mensagens encriptadas; tirava aspectos, pam, mensagens plain text. Fantástico! Comecei a sonhar com uma camada de persistência não intrusiva, toda feita com aspectos. Aí conheci RUBY e o "alias". Fiz tudo que fazia com aspectos sem esquentar a cabeca com pointcuts, advices e outros blah blah blahs. Resultado: brochei de Aspectos. Hoje, quando Aspectos me vêm à mente, tem uma tag mental escrita: "classes abertas + alias, ponto final". Já tentei não pensar nisso, mas não adianta, encalacrou... Brochante 4: Portlets Quando vi, achei uma boa idéia. Era a componentização para web, finalmente! Com um pouco mais de trabalho, a idéia serviria pra fazer componentes que poderiam ser utilizados em aplicações "não-portal". Comecei a estudar... De cara, achei muito tosco, submeter todo o form e tentar manter o estado de cada Portlet era uma gambiarra sem fim... Mas vá, ossos do ofício, já que a web funciona assim. Comecei a achar que componentes pra web não eram lá uma idéia muito boa (ainda acho isso...). Aí apareceu o Gmail, com intenso uso de AJAX. Olhei pros Portlets, pensei em como fazer eles em AJAX e pensei... "poisé, tou perdendo tempo"... Sei que AJAX tem muitas limitações, conheço elas porque uso muito AJAX. O que só reforça minha idéia de que "aplicação web não pode ser pensada como se fosse desktop". Mas sinceramente, entre eles e Portlets... : Brochante 5: Java Essa foi engraçada, brochei antes de conhecer a linguagem. Em meados de 2000 eu trabalhava com Perl Orientado a Objetos (é... existe sim), e fiquei curioso quanto ao Smalltalk, já que todos os lugares falando sobre orientação a objeto mencionavam Smalltalk de um jeito ou de outro. Resolvi aprender... Fiquei maravilhado com a linguagem: simples, poderosíssima, ambiente integrado onde eu alterava os sistemas "à quente". UAU! Aí apareceu a oportunidade de trabalhar com Java, uma vontade que eu tinha desde os tempos de faculdade, pois todo mundo elogiava. Cheguei cheio de espectativas: "Java é bem mais novo, é orientado a objetos e deve ter todos os conceitos do Smalltalk, mas com tipagem forte!" ... Frau frau frau... Brochação geral... Collections ridículas, sem closures, pouca extensibilidade, ciclo de compilação full e nada de alterar a coisa "à quente". E a tipagem estática mais atrapalhava do que resolvia. Conclusão: Hoje gosto muito do Java e desde lá venho usando ele 8 horas por dia, 5 dias por semana. Mas se me perguntarem se é a melhor linguagem pra programação... beeeeemmmm... tenho saudades de collections com closures... Lições aprendidas... O que foi que aprendi com essas "brochações"? Aprendi que nem toda idéia do "mainstream" é uma boa, e a olhar propaganda com muita desconfiança. Aprendi que é bom olhar o underground da computação em busca de idéias novas, ou pior, de velhas idéias fantásticas que nunca caíram no gosto da maioria. Hoje sei que sou um programador melhor a cada vez que gasto tempo aprendendo algo que me faz pensar diferente... ando aprendendo LISP... espero que dê frutos (já deu, pra ser honesto)