Resolvi aproveitar a promoção de lançamento do site do carrefour, que dava 20% de desconto em qualquer produto do site e comprei o tão sonhado iMac de 27″. 20% de desconto em cima do preço da Apple Store fez uma grande diferença, pode acreditar :) Cheguei de viagem este fim de semana e enfim hoje uma notícia boa, chegou meu iMac. :)

Ponto mega-positivo: Tela. Não podia imaginar a qualidade desse display de LED. É fantástico. Em relação a tamanho, já estava usando um Samsung de 24″, mas o brilho, a definição do display de LED da Apple é fora de sério. Tirando ainda a resolução alcançada, de 2560 por 1440.

Preciso agora encontrar uma maneira efetiva de manter um sincronismo REAL entre os dados do iMac e do MacBook. Não queria nem algo web-based como dropbox ou sugarsync, seria alguma coisa normal mesmo, talvez até quem sabe um rsync possa ajudar. Se você tiver alguma opinião ou sugestão, me salve :)

Sobre o problema de flickering reportado por aí a alguns meses, achei que pudesse estragar a minha alegria, mas não, logo que liguei, junto com as atualizações, já veio um firmware do LED pra deixar tudo OK. :)

Segue algumas fotos do unboxing.

Lucas,
gostaria de saber como trabalhar com arquivos .properties pra conexão com o banco de dados.
No Grails a gente nota que a conexão fica no código-fonte (DataSorce.class)…
Estou tentando descobrir como faço para ter um arquivo de propriedade com os parametros da conexão. Caso eu precise apontar para outro banco, não terei que recoompilar tudo.

production {
   dataSource {
      jndiName = "<nome_datasource>"
   }
}

Uma coisa que já está feita é a leitura da configuração do gsolr e a declaração mágica de beans, um para cada servidor solr que estiver configurado. Exemplificando, vamos imaginar que a configuração esteja declarando três servidores Solr que serão consultados:

gsolr {
   solr {
      produtos {
         (...)
      }
      noticias {
         (...)
      }
      usuarios {
         (...)
      }
   }
}

Particularmente, achei bem interessante usar o nome da closure para o nome do servidor ao invés de termos um atributo name = produtos :)
A mágica legal mesmo, é que o plugin vai ler esta configuração quando a aplicação for para o ar, e depois disso irá declarar / criar beans spring dinâmicamente, usando a Spring DSL. E os beans vão ter no nome a declaração feita na closure do usuário.

Ou seja, para os servidores solr declarados acima, o plugin irá declarar os Spring Beans produtosGSolr, noticiasGSolr e usuariosGSolr .

Desta maneira, vamos garantir que se você quiser o usar o plugin, o processo como um todo ficará o menos intrusivo possível, e você poderá usar os métodos (de pesquisa e outros) do GSolr apenas injetando o bean do servidor Solr que você quiser.

class PesquisaService {
   def noticiasGSolr

   def pesquisar = {
      (...)
   }
}

Achei no mínimo, muito prático. Tudo isso graças a Spring DSL que temos em groovy. Com um pouco mais de tempo, coloco o procedimento passo a passo para declarar os beans desta maneira. Enquanto isso, conheça um pouco mais sobre a Spring DSL aqui, ou veja o código fonte aqui e também aqui.

Tem alguma idéia ou sugestão para o plugin? Deixe um comentário!

Bastou eu levantar os grupos/artifactsId e versão do solr-core e do solrj (1.4) e adicionar no meu BuildConfig.groovy. Consegui estas informações no próprio wiki do solr, nesta página: http://wiki.apache.org/solr/Solrj#Maven

Depois disso, bastou adicionar um repositório para buscar os jars

repositories {
    mavenRepo "http://mirrors.ibiblio.org/pub/mirrors/maven2"
}

E declarar as dependências que eu precisaria em runtime:

dependencies {
    runtime 'org.apache.solr:solr-core:1.4.0'
    runtime 'org.apache.solr:solr-solrj:1.4.0'
}

Estamos levantando alguns pontos que seriam essenciais e interessantes para um plugin grails que cuidasse disso. Se você gosta também de Solr, ou está interessado, acompanhe os e-mails na Grails-Users ou no nabble aqui.

Você usa solr? O que acha interessante nele que deva existir em um plugin grails?

Este procedimento é simples e facilmente descrito em dois simples passos:

1. Driver do banco de dados: Você deve copiar o jar do driver JDBC do seu banco de dados para dentro da pasta <jboss_home>/common/lib
2. Configuração do DataSource: No jboss ela é feita através de um arquivo XML. Após criar este arquivo, tenha certeza que o salvou dentro da pasta <jboss_home>/server/<seu_server>/deploy.

No meu caso, o arquivo se chama database-ds.xml e possui as seguintes tags (são altamente descritivas, acredito não precisar detalhar):

<?xml version="1.0" encoding="UTF-8" ?>
<datasources>
  <local-tx-datasource>
    <jndi-name>jdbc/databaseDS</jndi-name>
    <connection-url>jdbc:mysql://localhost:3306/banco_dev</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>root</user-name>
    <password>senha</password>
    <min-pool-size>5</min-pool-size>
    <max-pool-size>30</max-pool-size>
    <idle-timeout-minutes>1</idle-timeout-minutes>
    <prepared-statement-cache-size>32</prepared-statement-cache-size>
  </local-tx-datasource>
</datasources>

Agora para acessá-lo basta buscar pelo nome JNDI java:jdbc/databaseDS, ou no meu caso, como é uma aplicação grails, usar a declarativa no DataSources.groovy

production {
  dataSource {
    jndiName = "java:jdbc/databaseDS"
    dbCreate = "update"
  }
}

Já tinha acompanhado na grails-users que existem alguns problemas para efetuar o deploy, e para cada um deles, uma sequência de passos obscuros para fazer o deploy acontecer com sucesso. Minha versão de grails neste procedimento é a 1.2.1 e do JBoss é a 5.1.0.GA

Efetivamente, o que acontece é que jboss traz junto com suas common libs vários jars que são empacotados juntamente com a sua aplicação quando você utiliza o comando grails war.

Existem alguns workarounds na internet que te mostram como modificar o BuildConfig.groovy (arquivo que define propriedades do empacotamento de sua app) para que após montar a estrutura de arquivos que irão ser empacotados, remova estes arquivos (principalmente o log4j onde o problema é mais aparente) do chamado stagingDir e os deixe de fora do pacote final.

Particularmente, achei a solução um tanto quanto diferente e acabei achando no FAQ do Grails e depois com mais detalhes nesta página uma solução menos intrusiva ao pacote, que é definir a prioridade de carregamento dos jars da aplicação.

Bom, para isso, precisamos criar um arquivo jboss-web.xml dentro do diretório WEB-INF de nossa aplicação que irá mostrar ao jboss que queremos “blindar” nossa aplicação para utilizar os jars que estão dentro de seu lib, e que estes por sua vez não deverão ser sobrescritos pelos jars do classpath do servidor. O conteúdo do arquivo segue abaixo:

<jboss-web>
   <context-root>/projeto</context-root>
   <class-loading java2ClassLoadingCompliance="false">
      <loader-repository>
         projeto:archive=projeto.war
         <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
      </loader-repository>
   </class-loading>
</jboss-web>

Na tag context-root estamos apenas aproveitando que a aplicação terá seu arquivo de configuração específico para o jboss e definindo o contexto em que ela será publicada. Nas tags seguintes pedimos para o jboss criar o nosso classloader isolado, com o nome “projeto:archive=projeto.war”. Com este nome (que deve ser único, por isto leva em consideração o nome do projeto), garantimos que as classes pedidas pelo nosso projeto serão procuradas ali, e caso não encontradas, nos classpaths seguintes (common/lib, depois no tomcat).

Basicamente isto seria suficiente para conseguir que o projeto rodasse sem problemas. Porém no meu cenário de versões (grails 1.2.1 e jboss-5.1.0.GA) existe outro ponto de conflito. O Hibernate Validator que está junto ao jboss também difere em versão e gera conflito com o grails. Neste caso a solução é ainda mais interessante e simples que a anterior.

Para resolver o problema no deploy que indica claramente problema de versão no Hibernate Validator, basta que você faça o download da última versão deste jar (no meu caso, 4.0.2-GA) nesta url: https://www.hibernate.org/30.html. Depois disto, resta apenas colocar o jar do hibernate validator dentro da pasta <jboss_home>/common/lib.

Pronto, a aplicação está rodando e funcional dentro do jboss!

10:36:32,815 INFO  [[/projeto]] Initializing Spring root WebApplicationContext
10:36:41,155 INFO  [[/projeto]] Initializing Spring FrameworkServlet 'grails'

PS: Vale lembrar que o arquivo jboss-web.xml é padrão para arquivos war, se você quiser configurar a ordem do classpath para aplicações ear ou sar, consulte o link acima para entender as diferenças.

def myAction = {
render g.formatNumber([number:5000.234, type: "number", maxFractionDigits: 2])
}

Esta função é equivalente a chamar a taglib de dentro de um gsp da seguinte maneira:

<g:formatNumber number="5000.234" type="number" maxFractionDigits="2" />

Mas quando precisamos fazer isto, por exemplo, dentro de um service, encontramos um probleminha chato, as taglibs não são injetadas automaticamente. Para contornar essa “situação“, temos que buscar a taglib manualmente, da seguinte maneira:

def myTag = grailsApplication.mainContext.
            getBean('org.codehaus.groovy.grails.plugins.web.taglib.ApplicationTagLib')
def value = myTag.formatNumber([number:5000.234, type: "number", maxFractionDigits: 2])

Ahhh, para isso não se esqueca de injetar o objeto da grailsApplication da seguinte maneira

class MeuService {
   def grailsApplication
   (...)
}

Bin-go.

O sistema gravaria o conteúdo de um arquivo (plain xml mesmo) dentro do banco de dados, para evitar dependências com filesystem. Mas este arquivo também precisaria ser lido posteriormente. A solução que estava disponível, era alguma coisa mais ou menos assim:

def arquivo = Arquivo.get(params.id) //recupera o arquivo da base
render arquivo.texto

Legal, desta maneira (bem simples até), o conteúdo deste texto seria renderizado na página para o usuário poder salvá-la.

Imaginei que isto pudesse ser incrementado um pouco, e percebi que fazer com que o usuário tivesse que salvar a página (que continha apenas o XML) poderia se tornar um tanto chato com o passar do tempo. Resolvi alterar a action para devolver o texto em anexo ao response. Isso mesmo, com a caixinha para poder salvá-lo.

Olha que simples:

def arquivo = Arquivo.get(params.id) //recupera o arquivo da base
response.setContentType "text/xml"
response.setHeader "Content-Disposition", "attachment;filename=\"${arquivo.nome}.xml\""
response << arquivo.texto

Simples, colocando a instrução no header para que a “disposição” da resposta seja “attachment” (anexo), o browser ao invés de renderizar apenas o conteudo, retorna um arquivo com este texto.

Caso queira definir um locale default para sua app, basta sobrescrever o bean localeResolver no seu beans.groovy como abaixo:

beans = {
  localeResolver(org.springframework.web.servlet.i18n.SessionLocaleResolver) {
    defaultLocale = new Locale("pt", "BR")
    java.util.Locale.setDefault(defaultLocale)
  }
}

Sim, estou trazendo aos poucos tópicos que estavam em meu outro blog, blog.lucastex.com, dê uma passada por lá.

Para isso, é só declarar a tag dataSource do data-config.xml desta maneira:

<dataSource user="" password="" jndiName="JndiDoMeuDs"

Sim, os parametros user e password devem ser declados vazios, não se esqueça disso.

Muito legal, bem abrangente, fala um pouco sobre cada coisa, desde implementações básicas necessárias de DataImportHandler, Transformers, Term-Suggest, Types e outros pontos.

Solr 1.4 - Enterprise Search Server

Foi lançado um pouco antes da versão 1.4 estável sair (por todo aquele problema do último bug do lucene e etc), por 2 dos committers: David Smiley e Eric Pugh.

Está custando $40 diretamente no packetpub: A url para o produto é esta: http://www.packtpub.com/solr-1-4-enterprise-search-server/book.

Recomendo a todos que se interessam pelo assunto, e trabalham com isso, guia de consulta imprescindível :)

Acabei descobrindo, da maneira ruim, que no Grails, quando lêmos a configuração da aplicação (Config.groovy) através da referência grailsApplication.config estamos manipulando uma variável passível de alterações, ou seja, qualquer atributo que você recuperar de lá, e modificar, assim estará para toda a execução.

Na minha situação, eu mantinha uma lista de e-mails lá no arquivo de configuração para que quando disparado, eu pudesse enviar o e-mail a estes destinatários somados ao e-mail do usuário, que tinha acabado de ser inputado no formulário. Tinha algo assim:

contato.destinatarios = ["email1@xpto.com", "email2@xpto.com", "email3@xpto.com"]

E dentro do controller, usando o mail plugin (leia este post sobre o mail plugin), executava o seguinte trecho de código:

def destinatarios = grailsApplication.config.contato?.destinatarios?.toArray()
destinatarios << params.email
sendMail {
    to destinatarios
    subject "Contato ..."
    body "......"
 }

Ou seja, quando eu pegava a referência dos destinatários do Config, eu mantinha essa referência em ‘destinatários’. Quando eu adicionava neste array o destinatário que vinha do formulários “params.email”, eu alterava a *instância* e referência da configuração da aplicação, e aquele e-mail ali ficava.

Resultado, no primeiro contato, receberam o e-mail a lista de destinatários e o primeirocontato@xpto.com, na segunda execução, todos eles da configuração, o primeirocontato@xpto.com e também o segundocontato@xpto.com foram copiados.

E assim sucessivamente.

Vivendo e aprendendo, tomem cuidado com isso!

Trata-se dos sites http://www.imoveisnomorumbi.com.br e http://www.imoveisnopanamby.com.br, site de duas imobiliárias do mesmo grupo, que negocia imóveis de alto padrão nestes dois bairros.

Algumas informações interessantes sobre o projeto:

Tecnologia e Infraestrutura: O site antigo usava SQLServer como banco de dados e tecnologia ASP. Como usamos Groovy e Grails, por trás temos uma JVM Java em execução, e o banco de dados, o bom e velho MySQL.

Antes, para suportar o ASP, o IIS era usado como web server, e agora Um apache balanceia as requisições aos dois Tomcats. Tudo isto está deployado e rodando em um Cloud Server da Locaweb, por opção do cliente, onde já mantinha a conta antiga.

Integração com o sistema legado: Para a integração do modelo de dados antigo e o novo modelo, construímos rotinas de importação dos dados usando Groovy SQL, uma maneira  fácil, muito fácil, de fazer rotinas em banco de dados.

Plugins utilizados: Ahhh, os bons e velhos plugins do Grails, não canso de dizer que esta é a melhor parte do Grails! Foram usados os plugins:

Grails-Mail, para envio dos e-mails e formas de contato do site
Grails-Acegi, para autenticação e segurança
Grails-Cookie, para manipulação dos cookies do cliente
Grails-Navigation para criação de menus/submenus da interface administrativa
Grails-RichUi para alguns componentes gráficos como auto-complete e nuvem de tags
Grails-RuntimeLogging, um ótimo plugin para moder trabalhar com o nível de log de cada artefato (controller, service, etc), da app em runtime
Grails-Settings para algumas parametrizações da aplicação.

E com certeza, se eu tivesse pesquisado com um pouco mais de tempo, teria usado outros plugins para evitar algum trabalho que tenha feito na mão. E é claro, além disso, bastante (mesmo) jquery, ajax e json.

É isso, qualquer dúvida sobre o projeto, como aconteceu, soluções e problemas, basta comentar!

Obrigado a todos!

Enfim, o Mail Plugin é um dos plugins mais antigos do Grails (acho que usei pela primeira vez em agosto de 2008), e um dos mais simples de ser usado. O primeiro passo é instalar o plugin como qualquer outro:

grails install-plugin mail

Com isso as dependências serão baixadas e o plugin será instalado.

Após isso, você vai precisar configurar o envio de e-mail.
De forma bem intuitiva novamente, diretamente em seu Config.groovy deverá setar as propriedades:

grails {
   mail {
      host     = "smtp.meuservidor.com.br"
      port     = 25
      username = "usuario@provedor.com.br"
      password = "eusoul33t"
      props    = ["mail.smtp.auth": "true", "mail.smtp.socketFactory.port": "587"]
   }
}

Ahhh, o exemplo acima já está pronto para usar validação de usuário e senha no envio, já que hoje (99%) dos servidores assim exigem. Pronto, com isso o plugin já consegue saber como o e-mail será enviado (por trás ele usa o envio de e-mails embutido no Spring, é claro).

Agora, quando for enviar um e-mail, basta usar a closure sendMail que é automaticamente adicionada em todos os seus controllers! Segue um exemplo:

sendMail {
   from "lucas@testedoblog.com.br"
   to "dest1@email.com", "dest2@email.com"
   cc "copia@email.com"
   bcc "oculto@email.com"
   subject "Enviando e-mails com Grails"
   body """
      E ai pessoal,
      Este e-mail foi enviado diretamente de um controller da minha
      aplicação Grails usando o Mail Plugin.

      Até mais."""
}

Pronto, agora é só checar as caixas de e-mail! Vale lembrar que as instruções cc e bcc não são obrigatórias!

O plugin suporta envio de anexos, conteúdo HTML e outras opções. Para mais detalhes, consulte a documentação oficial, ou deixe um comentário aqui.

Ahh, e se quiser usar uma caixa do GMail para enviar as mensagens, use a configuração abaixo.

grails {
   mail {
      host     = "smtp.gmail.com"
      port     = 465
      username = "seulogingmail@gmail.com"
      password = "suasenhadogmail"
      props    = ["mail.smtp.auth": "true",
                  "mail.smtp.socketFactory.port": "465",
                  "mail.smtp.socketFactory.class": "javax.net.ssl.SSLSocketFactory",
                  "mail.smtp.socketFactory.fallback": "false"]
   }
}

Feliz 2010, ao som de “Dream Theater – Don’t look past me”.

Por exemplo, temos o nome de um livro no nosso índice da biblioteca. Este nome deve ser flexionado no maior número possível de formas para que seja encontrado, seja removendo acentos, usando o snowball, o tokenizando e etc. Porém, ele também será usado em uma feature de “ordenação alfabética”. Neste caso sabemos que o campo deve ser indexado como “string” sem tokenização ou flexão, ou o resultado pode virar uma bagunça.

Grande parte das pessoas, enviam o campo duas vezes para o Solr, em dois fields diferentes, por exemplo: “nome” e “nome_ord”. Com isso, deixamos de usar uma diretriz bem bacana do solr chamada copyField que serve para copiar o conteúdo de um campo para outro.

Imaginando que os campos estejam definidos da seguinte forma:

<field name="nome" type="text" indexed="true" stored="true" />
<field name="nome_ord" type="string" indexed="true" stored="false" />

E usar no fim do documento a instrução copyField

<copyField source="nome" dest="nome_ord" />

Desta forma não adicionamos nenhum overhead de parse de uma nova informação, diminuímos a quantidade de dados enviada para o Solr (muito importante se estiver usando HTTP para indexação) e garantimos que a informação será exatamente a mesma.

Uma outra funcionalidade (esta disponível apenas a partir do Solr 1.4) é o maxChars que pode ser usado para restringir a quantidade de caracteres que serão copiados. Neste meu exemplo poderia ser usado para criar um resumo da introdução desta maneira.

<copyField source="introducao" dest="resumo" maxChars="3000" />

Boa!

Usaremos JDeveloper como IDE e JSF como framework web. Particularmente não tenho boas impressões de JSF nem do JDeveloper, mas como apenas conheço comentários e opiniões de amigos, acredito ser uma boa oportunidade para tentar entender e um pouco deles e poder formar uma opinião própria com propriedade . Mas já adianto, não vou me apaixonar :)

Enfim, precisei já instalar o JDeveloper no meu Mac, e como várias coisas no mundo Oracle, precisam de alguns ajustes para rodar sem problemas no Mac.

O primeiro passo, é baixar o produto diretamente do site. O arquivo já vem no genérico .jar, então para rodar é na base do clássico

java -jar jdevstudio11111install.jar

Só que por algum motivo ele não identifica os JREs instaladas por default no mac, para isso, um pequeno ajuste deve ser feito, criando um link dentro da pasta onde a instalação do JDeveloper irá procurar o JRE.

Lembre-se que este processo deve ser feito antes de executar a instalação do pacote. Se você já havia iniciado, encerre-a e comece novamente.

cd /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
sudo mkdir -p jre/lib
cd /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/classes/
sudo ln -s classes.jar ../Home/jre/lib/rt.jar

Pronto, agora basta iniciar a instalação padrão do JDeveloper sem mais problemas.

O link para download é: http://linorg.usp.br/apache/lucene/solr/1.4.0/

Segue abaixo o e-mail oficial de lançamento, que acabou de cair na Lista de e-mails do framework, enviado pelo Grant Ingersoll.

Apache Solr 1.4 has been released and is now available for public download!
http://www.apache.org/dyn/closer.cgi/lucene/solr/

Solr is the popular, blazing fast open source enterprise search
platform from the Apache Lucene project.  Its major features include
powerful full-text search, hit highlighting, faceted search, dynamic
clustering, database integration, and rich document (e.g., Word, PDF)
handling.  Solr is highly scalable, providing distributed search and
index replication, and it powers the search and navigation features of
many of the world’s largest internet sites.

Solr is written in Java and runs as a standalone full-text search server
within a servlet container such as Tomcat.  Solr uses the Lucene Java
search library at its core for full-text indexing and search, and has
REST-like HTTP/XML and JSON APIs that make it easy to use from virtually
any programming language.  Solr’s powerful external configuration allows it to
be tailored to almost any type of application without Java coding, and
it has an extensive plugin architecture when more advanced
customization is required.

New Solr 1.4 features include
- Major performance enhancements in indexing, searching, and faceting
- Revamped all-Java index replication that’s simple to configure and
can replicate config files
- Greatly improved database integration via the DataImportHandler
- Rich document processing (Word, PDF, HTML) via Apache Tika
- Dynamic search results clustering via Carrot2
- Multi-select faceting (support for multiple items in a single
category to be selected)
- Many powerful query enhancements, including ranges over arbitrary
functions, and nested queries of different syntaxes
- Many other plugins including Terms for auto-suggest, Statistics,
TermVectors, Deduplication

Getting Started
——————–
New to Solr?  Follow the steps below to get up and running ASAP.

1. Download Solr at http://www.apache.org/dyn/closer.cgi/lucene/solr/
2. Check out the tutorial at http://lucene.apache.org/solr/tutorial.html
3. Read the Solr wiki (http://wiki.apache.org/solr) to learn more
4. Join the community by subscribing to solr-user@lucene.apache.org
5. Give Back (Optional, but encouraged!)  See http://wiki.apache.org/solr/HowToContribute

For more information on Apache Solr, see http://lucene.apache.org/solr

Quando então foi lançado, o pessoal do Solr empacotou o framework como RC, disponibilizou para download e na hora do lançamento (pra ser mais preciso, um dia antes), dois bugs significativos foram levantados no Lucene 2.9. A equipe do Solr os avaliou com calma, entrou em alinhamento com os devs do Lucene (alguns fazem parte de ambas as equipes) e decidiram por bem aguardar o Lucene 2.9.1 para efetuar o anúncio oficial do Solr 1.4.

Pois bem, com o lançamento oficial do Lucene 2.9.1 hoje a tarde, o pessoal do Solr já correu, e empacotou em uma versão final a release tão esperada, 1.4.

Amanhã, dia 07, será feito o lançamento final do Solr 1.4 sem mais delongas. Pois bem, é só aguardar! Mas se você quiser dar uma olhadinha antes, é só baixar os pacotes antes de serem replicados para o mirror central entrando aqui: http://people.apache.org/~gsingers/solr/1.4.0/.

Eu, em uma olhada muito, mas muito rápida por cima de algumas funcionalidades do Solr 1.4 (direto no wiki), levantei alguns pontos e encaminhei na lista de e-mails dos colaboradores da empresa em que trabalho. Não estão agrupados, muito menos organizados, mas segue como esboço e rascunho de um post que valeria a pena.

• SolrServer – SolrJ HTTP
  • Configuração
    • Timeout
    • Quantidade de retentativas
  • SolrJ altamente evoluído para criação da queries e integrado aos searchcomponents
• DataImportHandler
  • Transformers
    • Clob Transformer: Permite pegar dados direto de colunas clob no banco de dados
    • HTML Stripper: Atua em campos com conteúdo HTML, removendo tags e deixando apenas o conteúdo
  • Agora é possível usar o DIH indexando até conteúdos de um ‘datasource’ de e-mail, deixando ele fazer pooling em um e-mail e indexando o que chega.
  • Eventos callback após indexação
• Replicação
  • Configuração interna a aplicação – Funciona como um RequestHandler
  • Dashboard de administração, permite ver como estão as replicações, qual indice está em cada nó, status do download de novos indices
  • Permite replicação interna, via HTTP, não sendo mais necessário usar apenas rsync
    • Com isso, possibilidade de usar em windows
    • Menos configuração de infra estrutura
    • Maior visibilidade do status da replicação
• Indexação
  • indexação de grandes quantidades de documentos via streaming
    • conexão é aberta com o master, e permanece assim enquanto necessário.
  • Anotação @Field para poder adicionar um POJO direto ao índice, sem ter que transformar em SolrInputDocument
• Componentes de busca (alguns presentes no 1.3 completos, outros eram beta, outros nem existiam)
  • Sugestão de busca
  • Spelling
  • Highlight
• Resposta da busca em vários novos formatos
  • php nativo
  • json (já existia mas não era oficial)
  • xml (normal)
  • ruby

E muito mais…

Neste caso, acaba tendo que abrir o source da página para conseguir ler o conteúdo.

Este plugin do safari, chamado XMLView Plugin com certeza me ajuda muito e pode te ajudar. É muito simples, basta descompactar seu conteúdo em $HOME/Library/Internet Plug-Ins e reiniciar o navegador.

Depois de reiniciar o Safari, abra qualquer XML e faça o teste! Use e abuse do layout bem definido e opções de expand/collapse dos nós. Veja abaixo um exemplo:

Safari vendo XML com o plugin XMLView Plugin

Se gostou, me deve um real. :)

É como eu estava dizendo para a @loiane e para o @cmilfont no twitter sexta. Não tem nada mais poderoso que javascript. :)

//insere faixas de preço para compra
$("<option value='0-200000'>Até 200 mil</option>").appendTo("#cmbValor");
$("<option value='200000-300000'>De 200 mil a 300 mil</option>").appendTo("#cmbValor");
$("<option value='300000-400000'>De 300 mil a 400 mil</option>").appendTo("#cmbValor");
$("<option value='400000-500000'>De 400 mil a 500 mil</option>").appendTo("#cmbValor");
$("<option value='500000-700000'>De 500 mil a 700 mil</option>").appendTo("#cmbValor");
$("<option value='700000-1000000'>De 700 mil a 1 milhão</option>").appendTo("#cmbValor");
$("<option value='1000000-2000000'>De 1 a 2 milhões</option>").appendTo("#cmbValor");
$("<option value='2000000-0'>Acima de 2 milhões</option>").appendTo("#cmbValor");

Para limpar o conteúdo do select, basta definir o html interno como vazio.

$("#idDoMeuSelect").html("");

Possuía uma lista de objetos (pogos) com várias propriedades, e a partir desta lista, eu precisaria de uma nova lista com apenas os ids de cada um destes objetos, ao invés da clássica iteração para se resgatar os valores, acabei usando o método collect, que recebe uma closure, e para cada objeto da lista, aplica esta closure!

Para quem conhece, funciona da mesma maneira que o FileFilter do Java, que é usado para filtrar arquivos dentro de um diretório.

def listaPogos = ...
def listaIds = listaPogos.collect { pogo ->
   pogo.id
}

Quer ver funcionando? Clique aqui para rodar o código no Groovy Web Console

Você pode acompanhar isto detalhadamente configurando seu DataSource.groovy para fazer isso com o parâmetro loggingSql. E o mais bacana na minha opinião é poder fazer isso de forma independente para cada ambiente. Lembre-se que por default esta configuração vem desligada.

environments {
  development {
    dataSource {
      url = "..."    //banco de dev
      loggingSql = true
    }
  }
  test {
    dataSource {
      url = "..." //banco de testes
    }
  }
  production {
    dataSource {
      url = "..." //banco de produção
    }
  }
}

No exemplo abaixo, um parâmetro nome é passado para a action, que faz uma consulta baseado neste parâmetro e nos nomes dos clientes.

def busca = {
   def clientes = Cliente.findAllByNomeIlike("%${params.nome}%")

   render(contentType: "text/xml") {
      results() {
         clientes.each {
            cliente -> result() {
               id(cliente.id)
               nome(cliente.nome)
            }
         }
      }
   }
}

Explicando o auto-explicativo:

Linha 2: Usamos um método dinâmico do grails (não, este método não existe na classe) que permite que eu localize todos os clientes (findAll) por seus nomes (byNome) Ilike (case insensitive) usando o parâmetro nome que veio no request. Esta lista é armazenada na referência clientes.

Linha 4: Pela funcão render deixamos claro que iremos renderizar um conteúdo text/xml

Linha 5: Esta será a nossa tag root do xml: results. A closure que se abre definirá os filhos deste nó.

Linha 6: Cada cliente na lista retornada…

Linha 7: Será um novo nó result do XML de resposta

Linhas 8 e 9: Os fois filhos de result, teremos o id do cliente e seu nome, suficiente para uma combo com auto-complete!
O resultado foi como esperado, e o tempo de fazer o exemplo funcionar foi definitivamente menor que o de escrever este post!

<results>
   <result>
      <id>313</id>
      <nome>JOSE DA SILVA</nome>
   </result>
   <result>
      <id>817</id>
      <nome>PATRICIA MARIA SILVA E SILVA</nome>
   </result>
   <result>
      <id>91</id>
      <nome>MARCOS SILVINO</nome>
   </result>
</results>

Agora é a vez do Grape, um módulo construindo em Groovy que abstrai toda aquela configuração do maven/ivy que vc teria por padrão. O grande diferencial do Grape, é que ele traz essa configuração mais para perto de quem precisa dela, ou seja, no próprio código fonte!

Funciona basicamente assim, você anota o seu método que irá precisar da dependência com a anotação @Grab dizendo qual é o grupo, artefato e versão da biblioteca que você precisa e pronto! Quando a classe for carregada, esta anotação irá disparar o download desta dependência automaticamente. Os arquivos que são baixados via grape são guardados dentro do diretório do usuário na pasta .groovy/grapes

Segue um simples exemplo que depende do commons-lang 2.4 e usa um método simples da classe StringUtils para trocar o case de uma string.

import org.apache.commons.lang.StringUtils

@Grab(group='commons-lang', module='commons-lang', version='2.4')
void testGrape() {

   def name = "Lucas Frare Teixeira"
   println StringUtils.swapCase(name) //lUCAS fRARE tEIXEIRA

}

//Chama a execução do método
testGrape()

Veja que a únca coisa que precisamos fazer, é anotar o método com a dependência e ele fica responsável por fazer o download.

Mas, conversando com o @paulosuzart do CodeMountain, chegamos a conclusão, que sistemas de maior porte, merecem um controle de dependências mais centralizado e até por que não dizer, organizado.

Ou seja, fica a minha dica de uso do Grape para a distribuição de scripts e arquivos pequenos, para evitar aquela coisa chata de enviar jars, setar classpath, ou então ter arquivos pom que definem dependência e etc.

Para evitar esta dor de cabeça, sem dúvidas o grape é ideal!

O que eu faço, é sempre renomear o pacote para: projeto-yyyyMMddHHmmss.[jar/war/ear] . Como ant, fica fácil fazer isso usando uma task chamada tstamp, que recupera o timestamp corrente e grava em uma variável seguindo o pattern que você escolher. Segue exemplo que uso aqui.

Armazenando valor:

<tstamp>
   <format property="build-datetime" pattern="yyyyMMddHHmmss"/>
</tstamp>

Pronto, agora basta usar a variável build-datetime como outra qualquer,

<target name="dist" depends="compile" description="gera o jar com a distribuição">
   <jar jarfile="${dist}/${project}-${build-datetime}.jar" basedir="${build}"/>
</target>

É uma boa também para guardar os arquivos em estruturas de pastas separadas por dia/mes/ano.

Possui todas as funcionalidades que existem em um sistema moderno de busca, como paginação, highlight de campos, flexão das palavras e etc. Na minha opinião, de tudo que trabalhei nos últimos anos, sem dúvida, formam o conjunto mais poderoso de frameworks.

O Solr abstrai a camada Java do Lucene e disponibiliza uma interface http para a execução da consulta, fazendo com que fique muito fácil a integração com sistemas não-java.

Um dos recursos avançados de indexação com Solr são os Transformers a serem usados juntamente com o DataImportHandler. Com eles, você pode processar o texto antes de ser indexado. (Um outro post sobre configuração básica de Solr e de DIH deve vir em breve).

Semana passada, precisei de um transformer que pudesse retirar todas as tags HTML do texto a ser indexado (malditos editores rich text em javascript). Como o projeto aqui está usando Solr 1.3 não tive a possibilidade de usar o HTMLStripTransformer que virá no Solr 1.4 (e está enroscado pra sair). Então acabei tendo que criar um semelhante para a funcionalidade.

A criação de transformers é muito simples (imho, simplista até demais, fazendo com que as vezes, o desenvolvedor se perca durante a implementação). Deve ser desenvolvida uma classe simples, que implementa um método com a seguinte assinatura:

public Map<String, Object> transformRow(Map<String, Object> aRow, Context context)

Quando disse que é simplista demais, é pelo fato de que, (imho novamente), condições restritivas como esta deveriam estar documentadas em interfaces, mas não, quando necessário, o método é chamado via reflection, tendo certeza que ele está implementado.

No meu caso, eu precisaria além de implementar o Transformer, deixar explícito no arquivo de configuração do DIH (data-config.xml) quais os campos que deveriam receber o tratamento desta tag, fiz isso adicionando a tag removeHtml no nó de cada campo (não, este xml não passa por validação).

<field name="txt" column="texto" removeHtml="true" />

Com isto, estamos deixando claro para o DIH que o valor que retornar da query na coluna texto será repassado ao Solr para indexação no field txt (definido no schema.xml) e terá processamento do meu HtmlTransformer. Ah, não podemos esquecer da declaração do transformer para a entidade:

<entity name="posts" transformer="br.com.lucastex.dih.transformer.HtmlTransformer" />

Pronto, a classe está agora carregada e pronta para ser chamada quando um campo necessitar. Agora, vamos a implementação da classse. No meu caso, ela ficou bem trivial, pois o campo em questão nunca será multivalorado (ou seja, não preciso tratar a possibilidade do argumento ser um List, mas apenas uma String.

package br.com.lucastex.dih.transformer;

import java.util.Map;

import org.apache.commons.lang.StringEscapeUtils;
import org.apache.solr.handler.dataimport.Context;
import org.apache.solr.handler.dataimport.DataImporter;
import org.apache.solr.handler.dataimport.RegexTransformer;
import org.apache.solr.handler.dataimport.Transformer;

public class CopyOfHtmlTransformer extends Transformer {

  public static final String TAG = "removeHtml";

  public Map<String, Object> transformRow(Map<String, Object> aRow, Context context) {

    for (Map<String, String> map : context.getAllEntityFields()) {
      if (!Boolean.TRUE.toString().equals(map.get(TAG)))
        continue;
      String columnName = map.get(DataImporter.COLUMN);
      String sourceColumnName = map.get(RegexTransformer.SRC_COL_NAME);
      if (sourceColumnName == null)
        sourceColumnName = columnName;
      Object value = aRow.get(sourceColumnName);
      if (value instanceof String) {
        String result = stripHtml((String) value);
        aRow.put(columnName, result);
      }
    }
    return aRow;
  }

  private String stripHtml(String text) {
    try {
      String cleanText = StringEscapeUtils.unescapeHtml(text.replaceAll("\\<.*?\\>", " "));
      cleanText = cleanText.trim().replaceAll("\n"," ");
      cleanText = cleanText.replaceAll("\t"," ");
      cleanText = cleanText.replaceAll("[\\s]+", " ");
      return cleanText;
    } catch (Exception e) {
      //trata exception de acordo com seu contexto solr
    }
    return text;
  }
}

Bom, o código é bem auto-explicativo. Basicamente recebe o além do contexto em execução do Solr/DIH, um Map de String e Object, que contém todos os campos e valores da linha que está sendo analisada/indexada no momento. Vale lembrar que este modelo de passagem de parâmetro é feito exatamente como descrito no Pattern BCDR.

Enfim, as linhas 18 e 19 garantem que o código só será executado para campos que tenham declarado a tag removeHtml=true como descrito anteriormente.

A linha 24 recupera o valor original do campo, ou seja, o que foi retornado pela query no banco de dados, e nas linhas 26 e 27 o resultado é tratado (através da chamada para o método stripHtml) e devolvida ao Map.

Ou seja, este é o momento onde você tem acesso a todos os campos que estão vindo do banco antes de irem ao índice. É nesta hora que você duplica seus campos, faz tratamentos, aplica padrões e templates, enfim trabalha a informação bruta original do banco de dados.

Já o método de remoção de tags HTML, não é nada além de um conjunto de regexes encadeadas  com uma ajudinha do StringEscapeUtils (que saudade deste post) do Commons-lang.

Simples como

Agora mesmo, eu precisava de um recurso para criar “slugs” (essas URLs amigáveis que o WordPress cria) de titulos de artigos. Tradicionalmente, o processo é criar aquelas classes **Utils.java com todos os métodos utilitários, mas com a metaprogramação, o mais usual passa a ser adicionar o métodos nas próprias classes que geram este comportamento.

No exemplo abaixo, eu adicionei o método slug() em runtime dentro da classe String e a partir de agora, qualquer objeto da classe java.lang.String possui o método slug(), com o comportamento descrito abaixo.

String.metaClass.slug { ->
    def s = delegate.toLowerCase()
    s = s.replaceAll(/[^a-z0-9\s-]/, "").replaceAll(/\s+/, " ").trim()
    if (s.length() > 45)
        s = s.substring(0, 45).trim()
    s.replaceAll(/\s/, "-")
 }

Em primeiro, definimos uma varíavel interna ’s’ com o valor da própria string que está sendo usada (através da propriedade delegate), após isso, aplicamos a primeira regex de caracteres especiais, outra para substituir os espaços em excesso e cortamos a string caso ela tenha mais que 45 caracteres. Por fim, substituímos os espaços por dashes.

Você pode rodar este script neste endereço, basta clicar em “Execute script”

O Elvis Operator é um operador em Groovy (já estará embutido no Java7) representado pelo “ponto de interrogação” seguido pelos caracteres “dois pontos” ou seja  ?:

O objetivo é fazer a comparação do valor de uma referencia a null, para decidir sobre uma atribuição de valor. Um exemplo bem comum é comparar o um parametro que vem do request de qual página irá ser mostrada de uma lista de objetos, porém, caso a página não esteja presente, devemos sempre mostrar a primeira página.

Tradicionalmente, em java, com o operador ternário:

Integer pageParam = (...)
pageParam = (pageParam == null) ? 1 : pageparam;

Com o elvis operator, ele já faz esta comparação implicitamente e caso o valor da variável seja null, recebe o valor que está a direita do operador.

def pageParam = (...)
pageParam = pageParam ?: 1

— Post editado as 18:10 do dia 22/10 —
Meu amigo @paulosuzart do CodeMountain fez um post sobre o Elvis Operator em Scala.
A gente sabe que não existe, mas ele criou um. Vale a pena conferir. :)

Não eu não concordo, closures só querem o seu bem, eis a razão.

Bom, uma closure nada mais é que um trecho de código! Mas o que difere este bloco de instruções chamado closure de um método? A grande diferença neste caso, é que as closures são um pouco mais flexíveis que os métodos, e por sua vez podem até ser passadas como parâmetro na chamada de outras funções, ou seja, podem ser atribuídas a uma variável.

Em java não temos closures nativas na linguagem, e uma das formas de tentar alcançar o objetivo é através do uso de classes anônimas, o que particularmente não me agrada muito, pela sujeira que fica no código.

Em um primeiro exemplo, mais simples, segue como definir uma closure, associá-la a uma variável e depois executá-la. (exemplo em groovy).

def c = {
    println "Testando o uso de uma closure"
}
c.call()

Este é um exemplo simples, onde a frase acima será impressa no console.

Para incrementarmos um pouco, podemos fazer com que nossa closure receba um parâmetro para usá-lo dentro da execução, além de criar um método que faça o uso dela. O exemplo abaixo mostra isto.

//definição da closure para dizer oi
def ola = { nome ->
    println "E ai ${nome}, tudo bom?"
}

//definição da closure para dizer tchau
def tchau = { nome ->
    println "To indo ${nome}, ate a proxima!"
}

//criação do método que fará o uso da closure
void falar(Closure c, String paraQuem) {
    c.call(paraQuem)
}

//invoke do método com as closures de parametro
//note que a closure é passada como se fosse uma variável qualquer
falar(ola, "Fulano")
falar(tchau, "Ciclano")

Mas uma das maiores vantagens que eu enxergo nas closures, é a possibilidade de definição delas em runtime. Isso mesmo, conforme você programa, pode criar uma nova closure e chamar uma função que precise dela! Vemos isso em ruby e groovy com frequência para métodos onde iteramos listas e mapas.

Por exemplo, as listas e arrays em groovy possuem um método each que recebe uma closure como parâmetro, esta closure define o que será feito com cada um dos items da lista/array em questão. O exemplo abaixo mostra a praticidade de se fazer a definição da closure inline, ou seja, sem criar uma variável para ela antes.

Em groovy

//groovy
def lista = ["Ferrari", "RBR", "STR", "Brawn", "Renault", "Williams"]
lista.each { equipe ->
    println "A equipe ${equipe} correu na #F1 em 2009"
}

Em ruby

#ruby
lista = ["Ferrari", "RBR", "STR", "Brawn", "Renault", "Williams"]
lista.each { |equipe|
    puts "A equipe #{equipe} correu na #F1 em 2009"
}

Em scala

//scala
val teams = List("Ferrari", "RBR", "STR", "Brawn", "Renault", "Williams")
teams foreach {
   team => printf("A equipe %s correu na #F1 em 2009", team)
}

Dá pra perceber que a closure foi criada já no momento em que ela foi usada. Desta maneira, além de fácil, um código muito mais limpo e fácil de ser entendido.

Acredite, closures são suas amigas, e estão aqui pra te ajudar, então aproveite!

Ahh, e fica a dica de sempre: Ler a documentação:

Closures em Groovy (wiki) (groovydoc) (definição formal)
Closures (Proc) em Ruby (doc) (wiki)
Closures em Scala (wiki)