Enfim chegou meu novo PC. Faz um tempo já que estava adiando comprar um computador de mesa para desenvolver e ficar mais a vontade em casa. Com o uso intensivo apenas de notebook a alguns anos, meu pescoço e minhas costas começaram a reclamar feio esse ano.
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.
Recebi uma pergunta esses dias por aqui.
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.
Quem enviou foi o Felipe Juliani.
Neste caso, devemos usar ao invés das conexões declaradas no DataSource.groovy, uma declaração de conexão com banco de dados via
JNDI.
JNDI é uma árvore de ‘nomes’ que referenciam ‘recursos externos’. O que isso quer dizer? Basicamente, que a sua aplicação poderá pegar uma configuração de fora da aplicação, diretamente de um “lugar” na JVM que alguém colocou. Seria mais ou menos um clipboard compartilhado, só que de objetos é claro :)
Então para o caso acima, nada melhor que deixar toda essa ‘configuração’ de conexão com o banco de dados do lado de fora da aplicação e fazer com que ela vá buscar apenas pelo ‘nome’ desta conexão. Pronto, desta maneira a configuração fica externa a nossa aplicação e feita diretamente no nosso container.
Bom, eu particularmente vejo três grandes razões para o uso de DataSources JNDI. A primeira é quando devemos tirar do desenvolvedor a (ir)responsabilidadade de dimensionar/configurar a utilização de banco de dados. Isso é um trabalho de infra estrutura, e se em algum determinado momento infra estrutura resolver aumentar o pool de conexões de banco da aplicação, consegue fazer isto sem encostar na aplicação, diretamente no container onde ela está rodando.
Outro motivo é a melhor utilização de recursos de banco de dados. Vamos imaginar um cluster de servidores de aplicação com 3 nós. Cada um dos nós roda uma instância da sua aplicação, que está configurada (diretamente no DataSources.groovy) com um pool de 10 conexões, ou seja, só de subir as aplicações, você terá 30 conexões com o banco já feitas. Com DataSources neste caso, todas as instâncias da aplicação poderiam ir buscar conexões com o banco de dados no mesmo DataSource, configurado uma única vez. Com isso, não precisamos necessariamente possuir 30 conexões abertas com o banco, pois quando uma instância necessita de todas elas, outra instância pode estar usando apenas 3 ou 4. É claro que para isso, além dos servidores e da aplicação, o seu DataSource também precisa estar deployado no cluster todo.
E o terceiro motivo, é o apontado pelo Felipe acima, que precisa deixar uma maneira fácil de trocar o banco de dados da aplicação. Com estes DataSources JNDI fica fácil também, já que a url do banco, driver, e credenciais estão do lado de fora, na configuração do DataSource.
E para criar este DataSource?
Bom, o primeiro passo é levantar em que container você está rodando a sua aplicação, pois cada um tem a sua maneira particular de configuração, seja jetty, tomcat, jboss ou weblogic. Além das diferenças durante a criação do DataSource, temos também diferenças na ‘formação’ do nome deles. No caso do weblogic por exemplo, o mais simplista neste quesito, você poderia ter um datasource com o nome de “PedidosDS”, já no JBoss, ele fica prefixado desta maneira: “java:<nome_datasource>”.
E depois disso, na configuração da sua aplicação Grails, na closure do environment específico que você quer, basta descrevê-lo desta maneira:
production {
dataSource {
jndiName = "<nome_datasource>"
}
}
