Arquivo → December, 2008
Básico do Groovy para quem for aprender Grails
Antes de começarmos a trabalhar diretamente com Grails, convém conhecer o básico do Groovy. Afinal de contas, é a linguagem por trás da ferramenta e, mais do que isto, trata-se também de uma linguagem muito interessante para se trabalhar (programadores Java podem ver varios detalhes da linguagem que realmente surpreendem).
O que é Groovy?
No site oficial da linguagem, Groovy é definido como uma “linguagem ágil e dinâmica para a plataforma Java com muitas ferramentas que são inspiradas em linguagens como Python, Ruby e Smalltalk, tornando-as disponíveis aos programadores Java, usando uma sintaxe próxima ao Java”. Se você já programa em Java, portanto, aprender Groovy não será uma tarefa de outro mundo: na realidade, a sintaxe do Groovy é práticamente a mesma que a do Java. A diferença está nos recursos adicionais que a linguagem oferece.
Antes de pormos a mão na massa, no entanto, devemos primeiro nos livrar dos preconceitos ligados ao Groovy, decorrentes da idéia de que trata-se apenas de “mais uma linguagem de script”. Sim: Groovy pode ser usada como uma linguagem de script (e funciona muito bem para este fim), porém também pode gerar código compilado em bytecode que, consequentemente, é integrado de forma transparente a código Java pré existente. Este é um dos pontos fortes da linguagem: código Java chama código Groovy (e vice versa) sem saber em qual linguagem o mesmo foi escrito. Aliás, esta é a tendência da plataforma Java agora: tornar-se mais popular por ser uma plataforma de execução do que uma linguagem de programação.
Sendo assim… os detalhes que importam:
Instalando o Groovy
Se você for usar Groovy apenas com Grails, que por sua vez já se encontra instalado em seu computador, não é necessário fazer nada, pois o Groovy já vêm embutido no Grails.
Caso contrário, a sua instalação é bastante simples. Basta baixar sua última versão em http://groovy.codehaus.org e descompactar o arquivo binário em um diretório de sua escolha. O único requisito para se usar o Groovy consiste na instalação do JDK 1.4 ou posterior. Em seguida, lembre-se de incluir o diretório bin da sua instalação do Groovy no path do seu sistema e também de possuir a veriável de ambiente JAVA_HOME definida em seu sistema.
Diferenças básicas entre código Java e Groovy
Como mencionado anteriormente, a sintaxe do Groovy não é muito diferente da que encontramos em Java. Os principais diferenciais consiste em:
ponto e vírgula opcional: se você for digitar apenas um comando em uma linha, não precisa digitar o ponto e vírgula. No caso de mais de um comando, no entanto, já é necessário.
Exemplo:
println "Sou um comando sem ponto e virgula. Não é legal?" println "Eu já tenho ponto e virgula no final. Sou mais tradicional"; println "Mais de um"; println "comando"; println "na mesma"; println "linha.";
conceito de verdade: Groovy extende o conceito de verdadeiro com o qual estamos habituados a trabalhar em Java. Além do conceito tradicional, Groovy também considera verdadeiro qualquer valor que seja diferente de null, tal como nos exemplos abaixo:
String str = "Sou uma string não nula"
String strNula = null
if (str) {
println "Eu com certeza serei impresso"
}
if (! strNula) {
println "Eu vou ser impresso, pois meu teste consistiu em uma string nula negada!"
}
“main opcional”: se estiver trabalhando com Groovy na forma de um script, pode considerar o seu arquivo de código fonte como um main. Tudo o que estiver fora das chaves será considerado código a ser executado, tal como no exemplo abaixo:
println "Veja, sou um script feito em Groovy"
boolean maiorQue(int a, int b) {
return a < b
}
println "Reparou como eu simplesmente 'ignorei' a função maiorQue e continuei imprimindo?"
Gerará a saida
Veja, sou um script feito em Groovy Reparou como eu simplesmente 'ignorei' a função maiorQue e continuei imprimindo?
Tudo é considerado objeto: ao contrário do Java em que possuimos tipos primitivos e não primitivos, em Groovy tudo é considerado objeto. Sendo assim, os tipos primitivos do Java são convertidos para suas respectivas classes encapsuladoras de forma transparente para o programador, tal como no exemplo abaixo:
int inteiro = 4; print inteiro.toString()
Uma maneira fácil de se habituar a este detalhe da linguagem consiste em compará-la com o autoboxing incluido na linguagem Java a partir da versão 5.
return opcional: a instrução return com a qual já estamos habituados a trabalhar em Java também existe em Groovy. Porém, é opcional. Dada uma função, o valor de retorno do último comando corresponde ao valor de retorno da mesma, tal como no exemplo abaixo:
boolean maiorQuetradicional(int a, int b) {
// a maneira "tradicional" de se trabalhar com Java
return a > b
}
boolean maiorQueGroovy(int a, int b) {
a > b // bem mais simples!
}
sobrescrita de operadores: tal como em C++, em Groovy você também pode sobrescrever os operadores básicos da linguagem, como ++, –, >, etc. (mais sobre isto mais tarde)
Groovy Beans
Groovy facilita muito a vida do desenvolvedor quando o assunto consiste em declaração de beans. Isto porque a linguagem já faz boa parte do trabalho para o desenvolvedor. Você não precisa ficar declarando métodos gets e sets: Groovy faz isto dinâmicamente para você!
Suponhamos que em Java, você precise implementar um bean tal como descrito abaixo:
class Pessoa {
private String nome;
private String sobrenome;
public String getNome() {return this.nome;}
public void setNome(String valor) {this.nome = valor;}
public String getSobrenome() {return this.sobrenome;}
public void setSobrenome(String valor) {this.sobrenome = valor;}
}
Em Groovy, você poderia declarar o mesmo bean apenas com o código abaixo:
class Pessoa {
String nome;
String sobrenome;
}
Se o escopo de uma variável é indefinido, Groovy entende que deverá criar dinâmicamente os métodos get e set para cada um dos atributos da classe. Sendo assim, boa parte da sua digitação torna-se desnecessária!
Claro, se quiser pode sobrescrever um get e set para customizar sua classe, tal como no exemplo abaixo:
class Pessoa {
String nome;
String sobrenome;
public String getNome() {
return "Sempre me chamarei José!"
}
}
Tipagem dinâmica
Em Groovy, o tipo das variáveis é definido opcionalmente. Se quiser, você pode defini-lo tal como faria em Java. Caso contrário, pode passar esta tarefa ao Groovy, que ele se vira pra você, tal como no exemplo abaixo:
def a, b a = 5 b = 6 def c = a + b // C será igual a 11. d = c + a + b // D será igual a 22
Para definir uma variável cujo tipo é indefinido, usa-se a seguinte sintaxe:
def [nome da variavel] [especificação do valor opcional]
ou, se preferir, simplesmente
[nome da variavel] [especificação do valor opcional]
Groovy utiliza duck typing para definir os tipos das variáveis. O que é duck typing? Simplesmente isto:
se age como um pato, é um pato.
No caso do Groovy, se uma variável age como sendo de determinado tipo (um número, uma string, etc.), então Groovy irá definir o seu tipo dinâmicamente desta forma.
Strings
Groovy simplifica muito a nossa vida na hora de lidar com strings. As strings com as quais você está a lidar são as mesmas com as quais estava acostumado em Java, porém com alguns detalhes a mais:
Para começar, há três maneiras distintas de se declarar strings em Groovy:
- Áspas simples, como ’sou uma string em aspas simples’
- Áspas duplas, como em “sou uma string com a qual você já está habituado em Java”
- Áspas triplas, como em
“”" sou uma maneira muito mais
interessante de se lidar com strings que
ocupem bem mais
de uma linha”"”
Há uma diferença entre o funcionamento destes três tipos de declaração: strings com áspas duplas e triplas permitem o acoplamento de strings, enquanto strings com áspas simples não. O que nos leva a mais uma útil novidade que Groovy nos trás:
Acoplamento de strings
Em Groovy, você pode incluir o conteúdo de uma variável ou o resultado de uma expressão dentro de uma string sem usar o operador + com o qual estamos acostumados (e irritados) em Java, tal como no exemplo abaixo:
int umInteiro = 5
String aspasDuplas = "Eu gosto do número ${umInteiro}"
String aspasTriplas = """Eu gosto muito do número ${umNumero},
mas também curto o seu dobro: ${umNumero + umNumero}"""
Como pode ser visto, a sintaxe é simples. Basta incluir em uma string dupla ou tripla os caracteres ‘${‘ seguidos de uma expressão ou valor e finalizá-lo com um ‘}’.
Closures
Closures é um tópico especial, razão pela qual você podera aprender mais sobre Grails neste link (ainda em produção).
Intervalos, hashes e coleções
Groovy inclui boa parte das Collections do Java na própria sintaxe da linguagem. Não é preciso referenciar o pacote java.util só para usar listas. Groovy já referencia este pacote automaticamente para você e ainda inclui algumas outras novidades tal como descrito abaixo:
Intervalos
Intervalos (no Groovy em Ação, são chamadas de escalas, porém acredito que o termo “intervalo” descreve melhor com o que estamos lidando) consistem em um recurso extremamente útil na linguagem. Você provávelmente é familiar ao senhor abaixo:
for (int i = 0; i < 10; i++) {
bla bla bla
}
O que temos dentro do loop, na realidade é um intervalo, porém descrito de uma das maneiras mais horrorosas possíveis. A questão que fica agora é: como isto poderia ser melhorado? Veja o código abaixo:
for (a in 0..9) {
bla bla bla
}
Este 0..9 consiste em uma escala, que implementa a interface Collection do Java. Sendo assim, é mais do que sintaxe: é um objeto por si só. Declarar uma escala é bastante simples. Basta usar a sintaxe abaixo:
[limite inferior]..[limite superior]
“..” consiste em um operador de precedência baixa, sendo assim é uma boa idéia sempre definir seus intervalos dentro de parênteses, tal como (0..9).
Se quiser, há também um outro operador que você pode usar ao definir escalas. O operador “..<”. Neste caso, estamos dizendo que o valor da direita não entra entre os valores da escala. O código em Java exposto no primeiro exemplo poderia portanto ser reescrito como
for (a in 0..<10) {
bla bla bla
}
Como mencionei, intervalos são objetos. Sendo assim, há alguns métodos e funções que você pode chamar, tal como no exemplo abaixo:
(0..10).contains(4) // Verifica se o intervalo contém o valor 4
(0..10).each {elemento ->
print elemento} // each executa uma closure (leia o tópico sobre closures para maiores detalhes)
Escalas só aceitam números? Não. Basicamente, aceitam qualquer tipo de objeto pode ser usado desde que as duas condições abaixo sejam satisfeitas:
- O tipo implementa próximo e anterior, ou seja, faz override dos operadores ++ e — (mais sobre sobrescrita de operadores aqui)
(Groovy sobrescreve os operadores ++ e — em java.util.Date e alguns outros tipos básicos para você) - O tipo implementa a interface java.lang.Comparable
Listas
Uma lista é declarada em Groovy usando a seguinte sintaxe:
[ (uma série de objetos separdos por vígula) ].
Exemplo:
lista = ["uma", "lista", "de", "strings"]
/*
Claro, você terá acesso também a todos os métodos da interface java.util.List
*/
lista.contains("uma")
lista.add("coisas da vida")
print "A lista possui ${lista.size()} itens!"
E ainda há alguns operadores bem interessantes para se lidar com listas, tal como no exemplo abaixo:
lista = [] // Como incluir um novo item na lista? lista += "primeiro item" // Como incluir mais de um item? lista += ["segundo", "terceiro", "quarto"] // E como eu removo um item? lista -= ["terceiro"]
Resumindo: seu código ficará beeem mais fácil de ser compreendido.
Mapas (hashes)
Mapas em Groovy também estão embutidos direto na sintaxe da linguagem, tal como pode ser visto abaixo:
def mapa = ["a":1, "b":2, "c":3] // Definição do mapa
/*
A sintaxe é simples: dentro dos colchetes, o elemento a esquerda do caractere ":" representa o índice, e o valor à direita, o valor
*/
// Claro, todos os métodos da interface java.util.Map podem ser chamados aqui, tal como
println "Eis que nosso mapa possui ${mapa.size()}"
println "E o valor de c é... ${mapa.get("e")}"
Aliás, em Groovy, você pode passar mapas para construtores de classes também, já as populando, tal como no exemplo abaixo:
class Pessoa {
String nome
String descricao
}
Pessoa pessoa = new Pessoa(nome:"Seu nome", descricao:"Um cara ai")
/*
O que Groovy faz aqui: ele recebe um hashmap, percorre suas chaves, as compara com os atributos da classe e os preenche.
Prático não acha?
Em apenas uma linha você economiza n!
*/
O que é Grails e como ele salva a plataforma JEE (além de lhe evitar o tédio)?
Se você chegou a esta página, é sinal de que tem pelo menos uma noção básica do que venha a ser Grails: um framework/plataforma utilizada na construção de aplicações web. Porém, para desenvolvedores Java já acostumados com os frameworks atuais, como Struts, JSF, Facelets e outros, trata-se de algo mais do que mais um framework com o objetivo de facilitar a execução desta tarefa. Trata-se de uma mudança de paradigma.
Até o surgimento do Grails, a história do desenvolvimento de aplicações web na plataforma JEE pode ser dividida, basicamente, em dois momentos:
- A criação da plataforma Java Enterprise Edition em 1999
- A introdução do Struts, que foi o primeiro framework de sucesso para esta plataforma.
Este segundo momento é importantíssimo, pois logo após a introdução do JEE, tornou-se claro que a maior dificuldade consistia no gerenciamento da complexidade das aplicações. Neste sentido, o Struts foi o salvador da pátria, ao aumentar significativamente a produtividade do desenvolvedor.
Após a introdução do Struts, outros frameworks foram surgindo, todos visando o mesmo objetivo: facilitar o desenvolvimento de aplicações web na plataforma JEE e, de um certo modo, se possível, superar o Struts. Dado que este foi um dos primeiros frameworks, a tarefa foi fácilmente cumprida.
Porém, após o surgimento de 298347203498234872634 frameworks, percebia-se nítidamente que, apesar de todos os avanços, os mesmos problemas voltavam a se repetir:
- Criar o ambiente de desenvolvimento normalmente consumia um tempo significativo
- Boa parte das tarefas repetitivas ainda eram executadas manualmente
- Não havia uma diretiva nítida a respeito de quais convenções seguir
- Com raríssimas excessões, a tarefa de configurar a aplicação foi se tornando cada vez mais complexa
- Os frameworks eram todos basicamente muito parecidos
- E o que considero mais importante: desenvolver aplicações web na plataforma Java foi se tornando cada vez mais tedioso.
A plataforma JEE como um todo, por sua vez, também apresentava um significativo aumento em sua complexidade, ao ponto de diversos desenvolvedores passarem a substituir parte de sua funcionalidade por ferramentas como o Spring e o Hibernate. Esta dupla aliás obteve tamanho sucesso que, na versão 5 da plataforma (que solucionou a maior parte dos problemas presentes até então) observa-se nítidamente a sua influência.
Eis que aos dois eventos citados anteriormente, surge um terceiro: Ruby on Rails (RoR): um banho de água fria para os desenvolvedores Java. De repente, uma linguagem que até então a maioria ignorava mostra um framework para desenvolvimento de aplicações web centenas de vezes mais produtivo do que todos os nossos frameworks java juntos. Naquele momento, pode-se dizer que Java como plataforma web era carta fora do baralho.
O que RoR nos trouxe:
- Uma aplicação prática do conceito de desenvolvimento baseado em convenções. Seguindo este paradigma, que basicamente nos diz: “olha, siga estas convenções que eu me viro com o resto”.
É incrível pensar hoje que algo tão simples era negligenciado por desenvolvedores Java. Até então, as “convenções” que levavamos em consideração diziam respeito apenas aos nossos famigerados arquivos XML (e cada componente com as suas próprias “convenções”)(o “rails” do nome faz referência justamente ao uso de convenções, que correspondem aos “trilhos” seguidos pelo desenvolvedor no processo de desenvolvimento)
- Stack completo: ao contrário do que ocorre em Java, no qual para criar uma aplicação usamos n componentes como por exemplo Hibernate, Log4J, Xerces, Commons, Spring e cia ilimitada, na qual passamos HORAS, e em certos casos, DIAS nos preocupando em como fazer com que tudo fique bem integrado, RoR trouxe uma série de componentes já pré integrados e prontos para uso. Ficar horas tentanto integrar componentes de uma hora para outra se tornou passado.
O desenvolvedor só precisava se preocupar com a sua lógica de negócios, e não com uma infinidade de detalhes técnicos que só atrasam seu trabalho. - Scaffolding: ao desenvolvermos uma aplicação web, boa parte do trabalho é repetitivo, como por exemplo a criação da camada de negócio (no caso de aplicações CRUD, isto se torna nítido) e controladores. Com RoR, o próprio framework, a partir de alguns modelos, cria para o desenvolvedor o esqueleto básico de sua camada de visualização e controle. Fica por conta do desenvolvedor apenas customizar estes arquivos de acordo com a necessidade de sua aplicação.(posteriormente neste trabalho irei mostrar que, na realidade, o scaffolding pode ser uma armadilha. Porém, por enquanto, vamos ver apenas o lado positivo do mesmo)
- Expansibilidade: em RoR é possível criar plugins que ampliem o poder do framework. Algo não lhe é atendido? Simples: crie um plugin. Apesar de já existir este recurso em diversos frameworks Java conhecidos, RoR conseguiu facilitar ainda mais a execução esta tarefa, elevando RoR do patamar de framework para o de plataforma.
Resumindo: RoR expunha a todos diversos dos problemas existentes no desenvolvimento de aplicações web usando a plataforma JEE. Estes eram simplesmente eram ignorados pela maior parte dos desenvolvedores, que até então os viam apenas como “ossos do ofício”.
Mas no caso da plataforma Java, que possui uma imensidão de bibliotecas existentes (a maior quantidade de biblioteca desenvolvida por terceiros na história) e código legado presente, como tirar proveito dos ganhos de produtividade obtidos pelo Ruby on Rails, um framework baseado em uma plataforma completamente diferente?
Duas foram as soluções:
- Implementar o ruby em Java. Eis que surge o projeto JRuby. Problema: a sintaxe e o modo de trabalhar do Ruby é muito diferente daquele com o qual estavam habituados os programadores Java. Consequentemente, a curva de aprendizado é muito maior.
- Implementar um framework baseado nos mesmos princípios do RoR na plataforma Java: surge o Grails.
Para o desenvolvedor Java acostumado aos frameworks até então, Grails se mostra completamente alienígena ao primeiro contato. Para começar, a linguagem usada não é Java, e sim Groovy. Por que Groovy?
- Possui uma sintaxe bem parecida com a do Java.
Na realidade, Groovy resolve algumas inconveniências da linguagem Java de uma maneira bastante elegante. - Trata-se de uma linguagem dinâmica. E linguagens dinâmicas, todos sabem, são bastante produtivas.
- É baseado na plataforma Java. Consequentemente, todo o código Java pré existente pode ser usado de forma transparente por código feito em Groovy. Não é preciso recompilar ou utilizar qualquer tipo de tradução, uma vez que código Groovy é compilado diretamente para bytecode.
(aliás, código Java também acessa código Groovy diretamente, pois no fina das contas, estamos lidando apenas com bytecode!) - É rápido. Código Groovy pode ser compilado, chegando a uma performance bem próxima (ou igual) a do código Java tradicional.
- Como o próprio nome já diz, é uma linguagem bem divertida de se usar. :)
Outra diferença diz respeito ao fato de se tratar de um ambiente completo de desenvolvimento. Ao baixar o Grails, o desenvolvedor já possuirá em sua máquina tudo o que precisa para começar a desenvolver suas aplicações. Traduzindo: Grails aposenta aquela velha história de ter de se ficar buscando arquivos jar na internet para se começar a trabalhar (no caso do Grails, isto é levado ao extremo. de cara o Grails já vem inclusive com seu próprio servidor de aplicações: o Jetty).
O ciclo de desenvolvimento também é bastante diferente. Ao desenvolvermos uma aplicação web usando JEE, normalmente o ciclo consiste em codificar, compilar, fazer o deploy da aplicação, testar e voltar a codificar. No caso do Grails, o ciclo consiste apenas em codificar, iniciar a aplicação e continuar alterando o código sem precisar ficar compilando e fazendo deploy o tempo inteiro (lembra muito o desenvolvimento em Lisp). Como resultado, o processo de desenvolvimento se torna MUITO mais agradável, aniquilando o tédio desta tarefa.
Sobre este guia
Este guia pretende ser o mais abrangente possível. Iremos ver desde o be-a-ba do Grails até tópicos mais avançados, como a criação de plugins e hacks que podemos aplicar ao framework.
Ao mesmo tempo, visto que não conheço Grails 100%, conto com a participação dos leitores em sua criação, razão pela qual estou disponibilizando o guia no formato de blog. Qualquer um poderá me enviar correções e novas informações a serem compartilhadas por todos.
Não há uma forma final para este texto e provavelmente jamais terá. Por estar em formato de blog,este constantemente será alterado, tornando o conceito de edições no nosso caso completamente sem sentido (Guimarães Rosa adoraria ter um blog). Dado que a forma final jamais será cristalizada, o texto não precisa ser seguido linearmente. Ao consultar algum dos tópicos presentes, você será informado dos pré requisitos necessários à sua compreensão, resultando portanto em um cookbook no final das contas.
(um cookbook com linearidade proposta, definida pela ordem na qual vou escrevendo os capítulos do guia)
Como mencionei, iremos começar do básico. No próximo capítulo, pretendo expor como é feita a instalação do Grails. A partir deste ponto, iremos acompanhar o desenvolvimento de algumas aplicações, cada uma expondo detalhes do funcionamento do framework (e, claro, vocês poderão dar o pitaco que quiserem durante o processo).
Uma maneira intergalática de se buscar fotos no Flickr
No Tag Galaxy, você busca por fotos no Flickr como se estivesse navegando por um planetário.
É bem bacana. Apesar de não ficar nítido de cara como se deve usar, em uns 30 segundos você se acostuma e fica maravilhado com o resultado: link: http://www.taggalaxy.de/
Ao ver o bichinho (feito em Flash), não deixo de imaginar o que poderemos ver em JavaFX em 2009.
Programação Orientada a Objetos em n linguagens (incluindo arquivos em lote do DOS!)
Eis que topo com este site: http://onestepback.org/articles/poly/
No mesmo, é exposto como atingir polimorfismo em diversas linguagens, incluindo algumas que não são orientadas a objetos. E, para meu choque, quem encontro no meio da lista? O bom e velho arquivo em lote do MS-DOS! http://onestepback.org/articles/poly/dosbatch.html
Aliás, há um exemplo também usando Shell Script, awk, sed e até Erlang (para a “infelicidade” do Joe Armstrong, pai do bichinho).
Realmente interessante ver como os paradigmas podem ser aplicados em outras linguagens que, pelo menos oficialmente, não os suportam.
Netbeans: pau no JUnit: forked JVM exited abnormally (ou como orelhei por MESES!)
Em alguns projetos desenvolvidos usando Netbeans, comecei a perceber o seguinte “bug”: só conseguir executar meus testes unitários se os debugo. Ao tentar executá-los, sempre era saudado pela mensagem “forked JVM exited abnormally”.
Postei o problema no site do projeto e em mais alguns fóruns e, para minha surpresa, ao que tudo indicava, o problema só ocorria comigo. Eis um sinal de que provavelmente o problema se encontrava entre a cadeira e o teclado. E eu dei atenção a este sinal? Bem… por MESES só executei meus testes unitários a partir do depurador, até que um belo dia, verificando as mensagens de erro impressas ao tentar profilar um teste unitário, me deparo com algo similar a ”não foi possível detectar qual versão do JUnit a ser carregada”.
Hmm… o que será? Verificando as bibliotecas referenciadas pelo projeto em questão, percebo uma em particular: “junit-x.x.x.jar”. Eis que surge a solução para o problema: o Netbeans já referencia o JUnit ao executar os testes unitários (claro!). Ao incluí-lo entre as bibliotecas do PROJETO, e não de testes, o classloader da IDE se confunde e, consequentemente, não consegue executar os testes corretamente.
Removendo a referência do projeto, o que ocorreu? Os testes voltaram a funcionar sem a necessidade de debuga-los!
Grails Corporativo: JMX e Log4j
Scott Davis acaba de publicar um excelente artigo sobre Grails no ambiente corporativo.
Realmente vale a pena dar uma lida: http://www.ibm.com/developerworks/java/library/j-grails12168/index.html?ca=drs-
Java: Algo sobre o classpath que eu não sabia (e talvez você também não)
Topei com este post, no qual é mencionada uma novidade do Java 6 que não conhecia: você agora pode usar caracteres coringa para definir o classpath da sua aplicação pela linha de comando!
A situação é bem conhecida: você possui uma aplicação que utiliza 293847203497823489762348976 jars. Então, é necessário definir o classpath da mesma. Primeiro executaria um comando como
java -classpath lib/commons-logging-1.1.1.jar:lib/commons-jci-core-1.0.jar:commons-io-1.2.jar:lib/junit-3.8.2.jar:lib/maven-project-2.0.8.jar:lib/rhino-js-1.6.5.jar: ...
ARGH!
Agora, no Java 6, é possível fazer algo como
java -classpath classes:lib/'*' Main
Bem mais simples. Claro: há ferramentas que fazem isto para você (Netbeans por exemplo). Só que para aqueles que ainda gostam de fazer as coisas no braço, segue o post citado acima. :)
Ainda mais informações podem ser encontradas neste link.
Programação Genética: recriando a Mona Lisa com apenas 50 poligonos!
Há algum tempo atrás, passeando por livrarias, topei com o livro “Algoritmos Genéticos” de Ricado Linden. Por curiosidade, o comprei e comecei a me interessar pelo assunto. No entanto, devo confessar que com o passar do tempo, simplesmente me esqueci do assunto.
Hoje, navegando pela internet, topei com um post entitulado “Genetic Programming: Evolution of the Mona Lisa” que reacendeu meu interesse pelo assunto. Basicamente, o autor mostra como, usando apenas 50 polígonos semi transparentes, ao usar a abordagem genética consegue reproduzir a pintura com um grau de precisão bem bacana.
Upgrade gigante no Grails Brasil – Participe!
Finalmente comecei a por a mão na massa e preparar a migração do Grails Brasil, atualmente baseado no phpBB (excelente por sinal) para… Grails! Apesar do Grails Brasil ser atualmente mantido pela itexto, acredito que, no final das contas, seja na realidade de seus usuários, razão pela qual o processo de desenvolvimento será 100% aberto a todos que queiram dar suas contribuições.
Uma pergunta que pode-se fazer portanto é: se funciona bem com a plataforma atual, por que migrar? Seguem as razões.
- Dado que nosso assunto aqui é Grails, nada mais natural do que fazer com que o Grails Brasil seja feito em Grails. Nem que seja para provar que a plataforma da conta (e bem!) do tráfego atual.
- Melhorar o controle de Spam. O grande problema do phpBB (sim, eu sei que existem soluções) consiste no spam. Apesar de já ter minimizado ao máximo o problema, de tempos em tempos este volta a atacar (e com força).
- Melhorar a manutenção do site. O phpBB oferece um painel de controle bem satisfatório, mas se no futuro for necessária uma migração mais forte do sistema, a coisa se complica. É fato: Grails é mais fácil de manter do que PHP.
- Simplificar o que já temos. Para as nossas necessidades atuais, o phpBB é complexo demais. Acredito que algo mais simples reflita em uma interface mais elegante para os usuários do sistema.
- Controle: apesar de possuirmos o código fonte do phpBB, não dominamos todos os seus detalhes. Com código fonte próprio este problema será solucionado.
- Pelo subproduto gerado: o foco inicial consiste em remodelar o Grails Brasil. No entanto, finalizado este processo, estará disponível para todos uma plataforma pronta para o gerenciamento de comunidades virtuais. Por enquanto, o nome deste subproduto será “Grails Community” (você pode opinar no nome também)
- Pelo aprendizado: neste processo, diversas dúvidas surgirão. E todas serão postadas no fórum do Grails Brasil, aumentando assim a nossa base de conhecimento.
- Por ser divertido ;)
Ontem já iniciei a base do código fonte com o basico do basico. Nem interface gráfica ainda possuimos, apenas as classes básicas de domínio e um script para a migração dos dados. Porém, algumas melhorias já são propostas:
- Visualização hierárquica dos posts. No fórum atual, a hierarquia consiste apenas em Categoria > Fórum > Tópico > Respostas. No entanto, é muito comum respondermos a uma das respostas presentes no tópico. Sendo assim, a nova hierarquia passará a ser Categoria > Fórum > Tópico > Tópicos > Tópicos > … > Tópicos
- Melhor mecanismo de busca, embutido em TODAS as páginas do fórum
- Comunicação em tempo real entre os membros (ainda não sei ao certo como implementá-la, mas é apenas uma idéia)
- Melhorias no blog (provavelmente continuará sendo baseado no Wordpress) e no Wiki
O mais importante, no entanto, consiste em deixar o processo aberto. Sendo assim, convido a todos os que se interessarem a participarem do projeto. A pergunta agora portanto deverá ser: como participar?
- Enviando-nos sugestões a respeito do que deveria ser melhorado no Grails Brasil
- Participando no desenvolvimento do código fonte do projeto.
- Acompanhando nosso desenvolvimento no nosso wiki grails-brasil
- Indicando-nos bons serviços de hospedagem aonde possamos hospedar o fórum, ou mesmo fornecendo patrocínio na hospedagem
O objetivo final consiste no fortalecimento da comunidade. Trata-se de uma daquelas poucas oportunidades em que todos saem ganhando e, espero eu, o maior número possível de pessoas. Sendo assim, espero por vocês neste novo projeto. Até lá!
Vista: dois anos depois, finalmente percebemos: é o Windows Me 2.0
Navegando pela internet, topei com este artigo, no site Microsoft Watch e, é incrível: aquilo que todos pensávamos, mas não diziamos está sendo dito: o Vista é na realidade o Windows Me 2.0.
Não vou repetir o que está escrito no artigo, porém convém citar os tópicos mais importantes:
- Menos de 10% das empresas migraram para o Vista nestes dois anos (fracasso total no mercado aonde a Microsoft tira o seu REAL faturamento)
- As pessoas não conseguiram se adaptar à sua nova interface (imagino como será com relação ao Windows 7, que é ainda MAIS diferente)
- Usuários continuam tendo problemas com o sistema.
- As pessoas não estão fazendo upgrade do sistema operacional.
É realmente incrível se for levar em consideração como as coisas eram alguns anos atrás. Após cada nova versão do Windows, TODOS migravam o mais rápido possível para a nova versão (com excessão do Windows Me). Eu me lembro de ficar ansioso pelas próximas versões do Windows.
Hoje, dois anos depois, só uso Mac (prestes a comprar mais um!) e Linux quando vou fazer trabalhos sérios. Em alguns clientes, ainda preciso usar o Windows, porém nestes casos, percebo que 90% das máquinas ainda estão com o XP instalado (e sem perspectiva de upgrade). Meu computador com Vista, a cada dia que se passa, vejo sua performance cair e meu desejo de substitui-lo por Linux crescendo (só não o faço porque (pasmem!) paguei pela minha cópia do Vista e não quero jogá-la fora).
Resumindo: o mundo mudou. O Windows não é mais tão relevante como era anos atrás. Hoje faço TUDO no meu Mac ou Linux. Aliás, tanto faz qual sistema opearcional estou usando, minhas ferramentas de desenvolvimento são multiplataforma, e os aplicativos que uso, em sua maior parte, são baseados na web.
Com base nestes pontos, fica nítido uma coisa: não somos mais prisioneiros do Windows. Se o acharmos uma merda (como está atualmente), basta trocar o sistema operacional. Um usuário convencional só precisa de um browser e de uma suite de produtividade como o OpenOffice (aliás, o próximo a perder a relevância será o Office) por exemplo.
E aí vêm a pergunta: a Microsoft vai sumir? Aposte que não. Com o dinheiro que tem, podem fazer merda durante décadas sem se preocupar com prejuízo. ;)
