Estou invadindo o Blog do meu grande amigo Lucas para postar uma solução que encontrei para um problema no mapeamento de dados de uma base de dados existente. Gostaria, em primeiro lugar, de agradecer o espaço cedido pelo Lucas e parabenizá-lo pelo excelente Blog.

Hoje em dia são poucos os projetos que precisamos desenvolver do zero — criar modelagem, tabelas e etc… — por isso é muito comum depararmos com padrões proprietários que muitas vezes não se “encaixam” na ferramenta de desenvolvimento. Não preciso dizer que não é uma tarefa fácil convencer os desenvolvedores a se adequarem aos novos padrões, então, se não pode com eles, una-se a eles.

Bom, vamos direto ao assunto, no meu projeto atual me deparei com um padrão que utiliza ‘S’ e ‘N’ para o mapeamento de propriedades booleanas no banco de dados Oracle. Na pesquisa que realizei encontrei várias pseudo-soluções mas a única que atendeu 100% as necessidades foi a implementação de um tipo de dados do Hibernate.

Abaixo a implementação da classe SNUserType, não tem segredo é apenas a implementação da interface org.hibernate.usertype.UserType. Salve este código no pacote persistence na pasta de src/groovy do seu projeto Grails.

package persistence;

import org.hibernate.*;
import org.hibernate.usertype.*;
import java.sql.*;
import java.util.*;
import java.io.Serializable;

public class SNUserType implements UserType {

   def SQL_TYPES = [Hibernate.YES_NO.sqlType()];

   public int[] sqlTypes() {
      return SQL_TYPES;
   }

   private Class targetClass;

   public void setParameterValues(Properties params) {
      String targetClassName = params.getProperty("targetClass");
      try {
         targetClass = Class.forName(targetClassName);
      } catch (ClassNotFoundException e) {
         throw new HibernateException("Class " + targetClassName + " not found ", e);
      }
   }

   public Class returnedClass() {
      return targetClass;
   }

   public boolean isMutable() {
      return false;
   }

   public Object deepCopy(Object value) {
      return value;
   }

   public Serializable disassemble(Object value) {
      return (Serializable) value;
   }

   public Object assemble(Serializable cached, Object owner) {
      return cached;
   }

   public Object replace(Object original, Object target, Object owner) {
      return original;
   }

   public boolean equals(Object x, Object y) {
      if (x == y)
         return true;
      if (x == null || y == null)
         return false;
      return x.equals(y);
   }

   public int hashCode(Object x) {
      return x.hashCode();
   }

   public Object nullSafeGet(ResultSet rs, String[] names, Object owner) throws SQLException {
      String value = rs.getString(names[0]);
      if ("S".equals(value))
         return true;
      else
         return false;
   }

   public void nullSafeSet(PreparedStatement ps, Object value, int index) throws HibernateException, SQLException {
      if (value == null) {
         ps.setNull(index, Hibernate.YES_NO.sqlType());
      } else {
         if((Boolean)value) {
            ps.setString(index, "S");
         } else {
            ps.setString(index, "N");
         }
      }
   }
}

Pronto, agora tudo que você precisa fazer é utilizar o novo tipo de dados no mapeamento de suas classes de domínio.

class Pessoa {

   String nome
   Boolean ativo

   static mapping = {
      ativo type: "persistence.SNUserType"
   }

}

Com isso, resolvi o problema de integração e concluímos este post.

Um abraço

Volnei

Essa semana teve na WWDC o lançamento oficial do iPhone 4, o novo aparelho da apple, e junto com isso, também o lançamento da nova versão do sistema operacional, antigo iPhone OS, que agora é chamado de iOS, na versão 4.

A mudança de nome era fato que estava pra acontecer, já que o sistema já está sendo usado no iPad, e não fazia mais sentido o nome ‘iPhone’ nele.

Bom, o aparelho iPhone 4 veio com vários recursos legais, mas que dependem de hardware, ou seja, só conseguiremos brincar quando tivermos o aparelho em mãos, como filmagem em HD pela câmera, a tela tipo ‘retina’, que segundo o Jobs, foi a maior melhoria no iPhone, já que trouxe *muito* mais precisão e sensibilidade para a tela do iPhone, que já era simplesmente animal. Além disso, também o giroscópio, processador melhor, e outras coisas.

Já outras funcionalidades que não dependem de hardware, apenas de software (no caso, o iOS4), podem ser atualizadas pra quem tem o iPhone 3Gs, (e alguns itens dela no iPhone 3G). Ontem atualizei o meu iPhone 3Gs e estou aproveitando muito. Hoje vou atualizar o iPhone 3G da @kapiologo pra ver efetivamente o que de diferente ele vai ficar.

Recursos legais do iOS4 (alguns já em uso massivo por aqui):

• Pastas de aplicativos – Chega daquela bagunça nas páginas, agora está enfim, tudo organizado em “Jogos”, “Financeiro”, “Inutil”, “Social”, e outras categorias
• Multi-task – Enfim o tão esperado multi-task. Agora basta um duplo clique no botão home para que todos os programas que estejam abertos venham a tona, e você pode alterar entre eles sem perder tempo de recarregar ou perder o estado da app atual, muito bom mesmo.
• Novo cliente de e-mail: Com e-mails agrupados em threads, como o gmail, agora fica mais fácil acompanhar listas de discussão também.
• Bluetooth para teclados: Ainda não usei, nem sei se serviria para alguma coisa, mas vou fazer o teste hoje a noite com o teclado do iMac.
• Camera fotográfica: Zoom digital – legal, e até mantém uma qualidade bem aceitável.
• Personalização com papel de parede no home – particularmente não muda nada pra mim, mas pra quem gosta… :)

Entre outros pontos, também existem os novos softwares como um tal de “Game Center” que não vi explicações muito convincentes em lugar algum, mas me parece ser uma app no estilo do antigo GameSpy (alguém jogava quake?) ou do Steam, para os jogos do iPhone, mas não tenho certeza. Também o iBook (que não está presente ainda, acredito que virá na atualização oficial do iOS4).

Bom, só que, como o mel nem sempre é tão doce, a Apple prometeu a atualização do iOS4 pra quem tem iPhone 3G/3Gs apenas para quando o iPhone4 começar a ser vendido nos EUA, e isso será no dia 21 de junho.

Só que como o pessoal que faz parte do Developer Program da Apple já tem acesso a versão, isso acabou vazando pela internet e pode ser encontrado facilmente, só que com um detalhe: Apenas para usuários — abençoados — que possuem um Mac em casa.

Por quê? Pelo fato que só se consegue usar o ipsw do iOS4 se for atualizado a partir do iTunes 9.2, que ainda está na versão beta.

Então se você é um desses felizardos de ter um iPhone 3G/3Gs e um Mac em casa, pode correr pra instalar a nova versão.

Eu encontrei o link para baixar o beta do iTunes 9.2 pro Mac aqui: http://hotfile.com/dl/47027679/1629379/itunes_9.2_beta.dmg.html
O ipsw do iPhone 3G: http://hotfile.com/dl/47027501/b933959/iPhone12_4.0_8A293_Restore.ipsw.html
O ipsw do iPhone 3GS: http://depositfiles.com/en/files/imajjlubx (links retirados do blog Addictive Tips)

Bom, como fazer? Depois de baixar, é o procedimento normal de atualização. Execute o DMG do iTunes, e faça a instalação (mantenha sua versão do iTunes fechada durante o procedimento). Depois de instalar, abra o iTunes, e ele irá atualizar toda sua Library, esse processo demorou uns 5 minutos em minha library com 50gb aproximadamente.

Depois, é sempre bom dar uma verificada se a versão foi instalada corretamente, então vá no ‘About iTunes’, no menu para checar se está com a 9.2 e pronto.

Conecte seu iPhone no Mac, após o iTunes reconhecê-lo, faça o backup do seu aparelho (botão direito no item iPhone -> backup).

Selecione o iPhone no menu esquerdo e na direita existirá uma opção “UPDATE”, clique nesta opção com a tecla “ALT-OPTION” do Mac pressionada, e uma janela de localização de arquivo será aberta. Basta agora selecionar o firmware ipsw para o modelo do seu aparelho que você baixou, e aguardar a instalação.

No final, o backup será restaurado, e o iPhone pronto para ser usado.

Incrível :)

Pra quem não pode estar presente, comecei a apresentação falando de groovy e fazendo um paralelo de uma aplicação Java e a mesma em Groovy, passo-a-passo mostrando os benefícios e vantagens que o groovy pode trazer para o desenvolvimento (o antigo caso do seletor de palavras).
Tentei deixar bem claro o tempo inteiro que o importante é gastarmos tempo *PENSANDO* em resolver o problema e não tentando aprender e entender como a linguagem de programação funciona.

Logo depois, passei por vários pontos do Grails, tentando mostrar como ele trazia os benfícios do Groovy para o desenvolvimento web. Passei pelo GORM (mapeamento objeto-relacional dinâmico), plugins, convenções e vários outros pontos. Pra encerrar a parte teórica, deixei alguns links e sites interessantes para que o pessoal pudesse consultar além de oferecer para os presentes cupons de desconto para a GroovyMag, revista focada em desenvolvimento Groovy e Grails.

Ao fim, apresentei uma aplicação simples, desenvolvida em bem pouco tempo que funcionava como um ‘twitter wall’, ou seja, fazendo buscas automaticamente no twitter de palavras previamente cadastradas, inclusive capturando automaticamente tweets do pessoal que estavam assistindo a palestra e twittando… :)

Bom, como eu já falei, foi muito bom, e além de satisfeito, fiquei muito agradecido, então não posso deixar de agradecer:
Principalmente ao Prof. Mauro Schneider (@muschneider), professor da Universidade que me fez o convite e viabilizou tudo isso, a Universidade não só o meu agradecimento, mas também os meus parabéns pelo ótimo evento. Aos meus amigos que me confirmara, e foram me apoiar e ajudar, Emerson (@erbernardino), Paulo (@paulosuzart), Leonardo (@leonardofigs), Rafael (@rafaelfelini), Luca (@lucabastos) e Jailton (@jailton). Ao Jailton, não só pela presença, mas também pelo apoio divulgando o evento na lista do SOUJava.

Pra quem quiser, a apresentação segue abaixo. E também 2 repositórios que criei no github, um com os fontes do projeto apresentado, e outro com a apresentação em HTML.

Repositório da apresentação: http://github.com/lucastex/slides-grails-umesp
Repositório dos fontes do projeto: http://github.com/lucastex/projeto-grails-umesp

O título da palestra será – “Grails – Java produtivo e divertido” e a entrada é liberada para quem quiser assistir. Vou falar de Groovy e Grails além da comunidade envolvida em torno dessas tecnologias. E ao final da apresentação, vou fazer algum hands on com o pessoal, desenvolvendo uma aplicação live com todos.

Divulgue em suas listas de discussões, empresa, amigos e inimigos, aproveitem que a entrada é liberada!

Data: 25 de maio
Horário: A partir das 19:00
Local: Universidade Metodista
Endereço: Rua Alfeu Tavares, 149 – Rudge Ramos – São Bernardo do Campo – SP

Mapa: http://maps.google.com.br/maps?f=q&source=s_q&hl=pt-BR&geocode=&q=Rua+Alfeu+Tavares,+149+Rudge+Ramos+-+S%C3%A3o+Bernardo+do+Campo+%E2%80%93+SP&sll=-23.581689,-46.642769&sspn=0.020551,0.046756&ie=UTF8&hq=&hnear=R.+Alfeu+Tavares,+149+-+Rudge+Ramos,+S%C3%A3o+Bernardo+do+Campo+-+S%C3%A3o+Paulo,+09641-000&ll=-23.609924,-46.548729&spn=0.16437,0.37405&z=13&iwloc=A

Depois da palestra, vou divulgar os slides e os fontes do hands on aqui no blog.

Ajude a divulgar, retwittando esta mensagem: http://twitter.com/lucastex/status/14333780136

[Atualizado!]

Vou distribuir uma edição grátis da Groovy Magazine (groovymag.com) para cada pessoa presente no local, compareça!

É um editor muito simples e pouco funcional, o que me fazia todas as vezes buscar o textmate para editar e trabalhar com os arquivos. Resolvi definir ele como padrão da seguinte forma

1. Localize algum arquivo com a extensão que quer mudar (no meu caso, .txt)
2. Vá em propriedades deste arquivo (ou selecione-o e aperte cmd+I)
3. Na ‘aba’ “Open with”, selecione o programa que deseja usar
4. Selecione o botão “Change All” para setar como padrão para todos os arquivos deste tipo.

Pronto, agora os arquivos TXT serão abertos diretamente no Textmate!

Este calcula o valor do envio de uma encomenda através dos Correios. Contempla SEDEX, SEDEX 10, SEDEX a cobrar e outros. O texto explicativo está bem simples e legal, e está no github junto com os fontes:

http://github.com/lucastex/correios-br

Mesmo os fontes no github, você pode instalar o plugin usando o comando padrão do grails:

grails install-plugin correios-br

Deem uma olhada nos docs do github, vale a pena!

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 resources.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
    }
  }
}