Uma coisa que ouço sempre na comunidade Java (falo dessa pois é a que conheço melhor) são os brados de “não reinventar a roda”. Cada vez que alguém aparece com um problema e fala de uma solução que algum projeto já resolve, desincentivam o programador completamente, falando que não vale a pena resolver novamente o problema já resolvido.

Eu não tenho como discordar mais de uma afirmação como essa.

A maior parte do tempo que dedico ao desenvolvimento fora do trabalho eu estou reinventando rodas. O Mirror é um exemplo disso. Dá pra fazer quase tudo que ele faz usando a API de reflection nativa do Java, mas é muito mais trabalhoso. Se eu não decido que reinventar a roda era uma coisa boa, eu não teria uma forma melhor de trabalhar com reflection. Além de que meu conhecimento sobre reflection não seria um décimo do que é hoje.

Além disso, tem um problema maior. Quando você usa uma camada de abstração, você ignora o que está acontecendo por baixo dos panos. Muitas vezes isso é bem importante, mas é bem perigoso também porque abstrações vazam. Em algum momento você terá que lidar com a infraestrutura que está embaixo da abstração e nesse momento, conhecer como a roda foi criada é fundamental.

Então, ao contrário do que a maioria diz, eu reinvento a roda sempre que posso. Depois que está funcionando e tem uma boa cobertura de testes, se for melhor (na minha opnião) do que existe no mercado eu extraio e lanço opensource. Caso contrário, migro meu código para uma das soluções existentes. Gastei mais tempo? Não. Fiz um investimento em mim (e provavelmente na minha equipe). Me tornei mais capacitado para resolver esse e vários outros problemas.

Mas é bom lembrar que você não vai poder fazer isso sempre (afinal, não se vive apenas de investimentos). Sem contar que reinventar a mesma roda sempre é bobagem (você vai aprender muito menos do que reinventando uma roda nova).

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

O post de hoje tem, novamente, a colaboração do nosso leitor Cacio Gazola. Mas desta vez foi ele que escreveu a base. Segue o texto adaptado:

Eu estava precisando fazer uma tabela assimétrica (onde uma célula da tabela ocupa várias colunas na mesma linha, sem afetar as outras linhas) e pesquisando nos blogs e fóruns a fora, nada encontrei. Apenas o conteúdo basico sobre tabela.

Até que encontrei, no wiki do LaTeX, uma dica interessante: o uso do \multicolumn {}{}{} para fazer o trabalho. Achei interessante pois em todos os tutoriais só mostram a aplicação do \multicolumn para a criação de texto em múltiplas colunas.

Dentro do ambiente \begin{table} e do \begin{array} funciona perfeitamente, e deve ter os seguintes argumentos: \multicolumn{número de colunas}{disposição do texto}{texto da célula}. As disposições possíveis são as mesmas disponíveis para tabela e array (l, c, r). Também suporta o caractere | para criar a borda interna da grade da tabela (por exemplo: {c|}). Com isso é possivel mudar a disposição do texto dentro desta célula, independente do indicado em \begin{table} por exemplo.

Segue um exemplo:
\begin{displaymath}
\begin{array}{rrrrrrr}
(1\times 2^3) & + & (1\times 2^2) & + & (0\times 2^1) & + & (0\times 2^0) \\
\Downarrow & &\Downarrow & &\Downarrow & & \Downarrow \\
8_d & + & 4_d & + & 0_d & + & 0_d \\
\hline
\multicolumn{7}{c}{\textcolor{red}{12_d}}
\end{array}
\end{displaymath}

Observe que todas as células devem ficar alinhadas a direita, menos a última que vai ocupar toda a linha e será centralizada.

Pois bem, aí me bateu um dúvida: se existe um multicolumn será que existe um multirow? E não é que existe!?

Ainda não cheguei a usar, mas encontrei uma página com as dicas de como fazê-lo:
http://andrewjpage.com/index.php?/archives/43-Multirow-and-multicolumn-spanning-with-latex-tables.html

Assim como o multicolumn, é necessário adicionar o pacote multirow no preâmbulo. Os dois juntos dão liberdade para criar tabelas totalmente assimétricas.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Semanas atrás eu apanhei bastante do Hibernate Search. Na verdade, não foi dele que eu apanhei, mas de não entender algo fundamental sobre ele.

Pra quem não sabe, o hibernate search é uma ferramenta muito legal para busca textual construída em cima do Lucene e do Hibernate. É realmente muito simples de configurar e usar. Mas tem um ponto que eu sabia mas não entendia as implicações.

O cenário era o seguinte. Eu tinha uma aplicação que usava lucene para fazer busca textual. Tudo era feito na mão e tinhámos uma boa suite de testes cobrindo a busca textual. Como a utilização do lucene foi em um momento experimental (fazer e depois melhorar), resolvemos migrar para hibernate search. Tirando o tempo que demorei para notar que a versão atual do hibernate search exige Lucene 2 e não o 3 que usávamos, dois testes insistiam em não passar por nada no mundo.

Todo o resto funcionava (o que praticamente garantia que a configuração estava certa). Depois de muito quebrar a cabeça, me lembrei de como o hibernate search funciona.

O hibernate possui uma estrutura de interceptadores para muita coisa interna dele, inclusive operações básicas com o banco, como inserir, atualizar, remover, etc.

O hibernate search entra exatamente nesse ponto. Cadastrando interceptadores para todas essas funções, ele é capaz de pegar os dados e serializar no índice do lucene também (notem que existe replicação de informação, uma vez que você terá os dados no banco e no índice do lucene). E esse é exatamente o ponto.

O teste que não passava era um teste que simulava o comportamento do usuário, usando WebDriver. Na funcionalidade em questão, não eram enviados todos os dados do objeto, apenas a chave primária dele. Com isso, o hibernate search indexava apenas a chave, pois todo o resto do objeto estava vazio. Quando me lembrei disso, foi necessário apenas fazer uma busca antes de mandar gravar o objeto.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Um de nossos leitores, o Cacio Gazola, perguntou-nos recentemente como o LaTeX sabe onde procurar os pacotes, fontes e configurações. Eu não sabia, mas fui investigar. Descobri, achei interessante e resolvi compartilhar aqui.

Os recursos extras da maioria das distribuições LaTeX (teTeX, TeX Live, fpTeX e miktex) ficam armazenados segundo um padrão criado pelo TeX Users Group. Esse padrão define uma estrutura de subdiretórios para agrupar cada tipo de recurso. As fontes de uma distribuição, por exemplo, devem ficar num subdiretório fonts/<tipo>/<origem>/<nome>/.

Mas isso ainda não especifica o caminho completo: falta saber dentro de qual diretório existe essa estrutura. Então como o LaTeX sabe onde fica essa estrutura de diretórios? Em tempo de compilação, define-se um diretório-raiz principal para a distribuição. É nesse diretório que vão ficar os pacotes e fontes padrão da distribuição, bem como os arquivos de configuração.

Mas você também pode criar um diretório-raiz seu, seguindo essa estrutura e com seus pacotes, e configurar o LaTeX para procurar pacotes nele. Como? Bom, isso depende de qual distribuição LaTeX você está usando e também de como ela foi compilada. Mas você pode descobrir onde ficam os arquivos de configuração principais da sua distribuição com o comando ‘texconfig conf’. A saída dele mostra as variáveis de configuração do seu ambiente LaTeX, inclusive a variável TEXMF, que contém os caminhos para todos os diretórios-raiz de pacotes LaTeX no seu sistema. É essa variável que você deve alterar, incluindo o caminho para seu diretório.

Com tantos diretórios e subdiretórios, e ainda a possibilidade de pacotes em vários lugares diferentes, como o LaTeX encontra os pacotes? Aí entra um programa chamado kpathsea. Ele cria um índice de todos os pacotes instalados. O LaTeX, na hora de processar um documento, chama esse programa para descobrir onde estão os arquivos de cada pacote referenciado pelo documento (pelos comandos \usepackage). Para saber mais sobre esse programa, use o comando ‘texdoc kpathsea’. Lá o autor do programa também conta a história do surgimento do kpathsea.

Posts Relacionados:

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.