Eu disse que iria postar menos sobre o DojoSEA aqui, mas não resisti ;-) Aqui está a versão do CampoMinado que deixamos funcionando no último Dojo:

Dêem uma brincada pra ver como está ficando. O código pode ser visto com um "botão direito -> view source" nessa página, ou então no github.

Aos que quiserem saber mais sobre dojo, dêem uma olhada nesse vídeo:

Aos que quiserem participar dos Dojos na SEA, entrem na nossa lista de emails, ou na do dojo-brasília.

Gente,

Essa quarta vamos continuar nosso problema do Minesweeper em Javascript, no mesmo horário de sempre, das 17:00 às 19:00. Compareçam!

Aproveito pra divulgar que criei uma lista de emails pra gente combinar as sessões, entrem lá pra gente descongestionar esse espaço aqui do blog e poder discutir mais sobre código e talz.

Aproveito pra deixar um texto curto bem legal, relacionado a TDD.

Nos vemos quarta!  o/

Moçada,

    Depois do carnaval, nosso Dojo ainda não conseguiu se levantar.

    Não me lembrei de blogar semana passada, mas dessa vez vou explicar.

    Essas duas últimas semanas foram meio turbulentas aqui na SEA por motivos que não cabem explicar aqui. O fato é que estamos fazendo uma força tarefa na SEA, com gente de todos os projetos, pra tentar agarrar uma oportunidade.

    Desse modo, achamos melhor suspender os Dojos por enquanto, pra não distrair o pessoal e pra respeitar o esforço coletivo da moçada.

    Semana que vem esperamos já estar de volta ao nosso ritmo sustentável e continuamos o problema do minesweeper javascript.

    Até lá!

Compre já a revista Mundo PM com o Willi correndo na capa! ;)

Pomodoro, GTD, Focus e muito mais!! (Na verdade, é só isso mesmo…)

Você pode adquirir a revista pelo site.

[]’s Willi

No último post apresentamos uma forma de desenvolver portlets em Rails, falamos sobre a variável de ambiente GEM_HOME, que define um path único para as gems de todas as versões do Ruby (incluindo o JRuby), dessa forma não precisamos replicar a instalação das gems nas outras versões e tudo fica muito bem, porém na prática a teoria é outra. Tivemos alguns problemas relacionados a gem PG. Em algumas máquinas o ruby ficava confuso sobre usar a versão jdbc ou a nativa da gem, mesmo configurado para usar uma ou outra. O erro era o seguinte:

NameError: uninitialized constant ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::PGconn

Para resolver esse problema tivemos que comentar a variável de ambiente GEM_HOME e instalar a versão java com o jgem, mantendo então as gems nativas do JRuby em seu próprio diretório de gems.

Prometemos um post sobre o liferay_models, mas ainda não será dessa vez. Nós criamos o projeto no github com algumas classes básicas, mas boa parte dele ainda está presa ao nosso projeto, isso deverá ser resolvido nas próximas semanas. Mas para não passar em branco, podemos adiantar algumas coisas sobre o projeto, como por exemplo as dependências da classe user_ do liferay, representada na imagem abaixo:

No liferay, por mais simples que um usuário seja, ele necessita de todas as dependências apresentadas, mais algumas que ainda não foram adicionadas. É nesse cenário que o liferay_models entra em ação, abstraindo as tabelas e os comportamentos das entidades, o que torna mais fácil a integração de um portlet escrito em Rails com o portlet container.

O fato de não utilizar o ambiente de extensão e desenvolvimento do portal implica em alguns problemas, como por exemplo, a integração com o apache lucene. Este framework é responsável por realizar a indexação de todo o conteúdo do portal, agilizando as consultas e melhorando a performance. Como o liferay_models trabalha diretamente com o banco de dados, sem passar pelas apis do portal, o conteúdo persistido por ele não é indexado pelo lucene, acarretando em alguns problemas como a ausência deste conteúdo nas pesquisas feitas nos serviços do portal. Estamos trabalhando nesse problema utilizando o jruby-lucene, que é uma api para manipular o lucene em ruby. Uma outra solução seria utilizar o solr, mas isso também fica para um próximo post. 

Falamos também do projeto rails-portlet que é uma ponte entre o projeto rails e o portlet container. Durante o desenvolvimento nós tivemos a necessidade de realizar upload de arquivos, e descobrimos de uma forma pouco agradável que o projeto não o suportava. Dessa forma começamos a saga da adição deste suporte a forms multipart ao rails-portlet, e como já era esperado, tivemos problemas.

1 - Apache fileupload vs Liferay

Round 1:
Tentamos utilizar o projeto fileupload da apache para receber os arquivos no lado servidor, mas tivemos a infelicidade de descobrir que o liferay eliminava (o.O) esses parâmetros antes da execução do rails-portlet, o que inviabilizava o uso do projeto da apache.

Round 2:
Utilizamos uma api do próprio portal para recuperar os arquivos, mas eles eram apagados antes do rails-portlet chamar o projeto em rails.

Round 3:
Já que os arquivos eram apagados, decidimos armazená-los na sessão durante a montagem da requisição para a aplicação rails, resolvendo o problema.


2 - Rack vs request multipart

Round 1:
Uma vez resolvido os problemas com o liferay, foi a vez do Rack atrapalhar, tratando os parâmetros do tipo string também como arquivo.
Basicamente o que acontecia era o seguinte:

O servidor recebia isso:

Parameters: {

"pessoa_fisica"=>{

"cpf"=>#<File:/tmp/RackMultipart4952-35>,

"foto"=>#<File:/tmp/RackMultipart4952-37>

}

}

Ao invés disso:

Parameters: {

"pessoa_fisica"=>{

"cpf"=>"123.456.789-00",

"foto"=>#<File:/tmp/RackMultipart4952-37>

}

}

O campo cpf, que era um textfield, virava um arquivo ao invés de simplesmente uma string.

Round 2:
Para resolver esse problema, tivemos que alterar novamente o rails-portlet, definindo o content-type dos campos do tipo string para null, pois o Rack na versão atual (1.1.0) trata qualquer parâmetro com content-type como binário, gerando o resultado apresentado acima.

Apesar dos problemas, conseguimos adicionar o suporte. Já temos no backlog uma lista de melhorias e novas funcionalidades, mas isso continua no próximo episódio.

Equipe CFA.

Só lembrando que quarta, às 17:00 vamos continuar nosso campo minado com JQuery & JSpec.

Semana passada começamos a mexer na lógica do jogo, mas ainda estamos bem no começo.

Compareçam!

Semana passada, começamos a implementar o campo minado com TDD, usando Javascript, JSpec e JQuery.

Até agora, só fizemos preparar o ambiente, desenhar uma tabela HTML que virá a ser nosso tabuleiro, e discutir um bocado (além de comer pizza).

Essa quarta (sempre às 17:00), iremos continuar o desafio.

Se quiser aparecer, sinta-se convidado!

[Só peço a gentileza de deixar um comentário confirmando quem vem (inclusive o pessoal da SEA), pra não encher demais - 10 pessoas é o limite!  ]

Ah, quem vier, tente chegar na hora, pois toda semana está aparecendo em nossa retrospectiva que estamos começando atrasados… :-(

Nessa quarta (17:00 - 19:00) vamos começar a implementar um joguinho de campo minado, 100% HTML e Javascript (JQuery), usando BDD e JSpec. Quer dizer, vamos tentar… :-)

Compareça.

Mas venha preparado: nosso objetivo não é terminar o joguinho, deixar ele impecável e bem acabado, e muito menos o de disputar quem sabe mais.

Venha disposto a comer uma pizza e conversar sobre código e metodologia.

(Se vier, dá um toque antes)

No final do ano passado fechamos um contrato com o Conselho Federal de Administração (CFA) para o desenvolvimento do cadastro integrado de administradores do Brasil dentre outras funcionalidades. Além da implementação, o CFA também tinha a necessidade de uma ferramenta capaz de prover recursos de CMS, comunidades, fóruns, etc. Tendo em vista esse cenário ficou decidido que o Liferay iria ser a ferramenta de portal utilizada enquanto o desenvolvimento dos portlets seria feito em Ruby/Rails.

Como seria possível desenvolver um portlet Ruby em uma plataforma Java? o.O? Utilizando JRuby é claro! Dentre os projetos que viabilizavam uso do Ruby/Rails em portlets java, o rails-portlet foi o que apresentou a melhor proposta. E como ele funciona?

• 1 portlet java
• O projeto feito com o Rails empacotado com a gem warble, rodando com o JRuby
• Comunicação HTTP entre o portlet e o projeto Rails
• Rails inacessível sem o portlet

O portlet java, que é provido pelo projeto rails-portlet, é adicionado ao portlet container e irá conversar com a aplicação feita em Ruby, isso facilita muito o trabalho, pois conseguimos desenvolver tudo em Ruby e com alguns comandos geramos o .war do portlet.

O projeto feito com o Rails tem algumas particularidades, a mais proeminente é o mapeamento das rotas, pois no projeto original cada método de controller gerava um novo portlet, um mapeamento fixo, por exemplo:

map.portlet_exemplo(

‘portlet_exemplo’, :controller => :controller_1, :action => :method_1

)   

Com as contribuições que nossa equipe fez ao projeto, nós conseguimos criar rotas que abrangem N controllers, o que melhorou bastante o processo de reaproveitamento de código, exemplo:

map.portlet_exemplo(

‘portlet_exemplo/:controller/:action’, :controller => :controller_1

)

Nessa caso, utilizamos um namespace ‘portlet_exemplo’ para definir o portlet e definimos que o controller padrão será o :controller_1 e o método padrão será o :index, que no caso, não precisa ser informado. Os wildcards :controller e :action serão substituídos pelos  valores passados por parâmetro na URL, por exemplo:

http://…/portlet_exemplo
controller_1, método index

http://…/portlet_exemplo/meu_controller
meu_controller, método index

http://…/portlet_exemplo/outro_controller/outro_metodo
outro_controller, método outro_metodo
 

Outra necessidade é a utilização da gem caterpillar que é a responsável por gerar automaticamente os xmls de configuração do portlet e do liferay, além de empacotar utilizando o warbler e realizar o deploy. Essa gem tem como dependência a gem lportal, que contém as tabelas do liferay na forma de modelos do ActiveRecord. Infelizmente o lportal não atendeu as nossas necessidades pois ele apresentou algumas problemas básicos, talvez por inatividade do projeto. Dessa forma nós criamos o projeto liferay_models, que ainda não está público, e que é assunto para um outro post.

Após o panorama geral, vejamos como criar um portlet em Rails.

1) Instalar e configurar o GEM

criar variável de ambiente $GEM_HOME=/caminho/das/gems/sem/a/pasta/gems
* Atenção: O caminho das gems não inclui a pasta gems.
Por exemplo:
export GEM_HOME=/usr/lib/ruby/gems/1.8

1) Instalar e configurar o JRuby

download
http://jruby.kenai.com/downloads/1.4.0/jruby-bin-1.4.0.zip

criar variável $JRUBY_HOME=/… e adicionar no path $JRUBY_HOME:$JRUBY_HOME/bin

1.5)
    apt-get install ruby-dev
    Ubuntu:
     apt-get install libpqxx3-dev
    Debian:
     apt-get install libpq-dev libpgsql-ruby

2) Instalar gems

gem install jruby-openssl
gem install jruby-jars
gem install hpricot
gem install warbler
gem install caterpillar
gem install lportal
gem install uuidtools
gem install rails -v=2.3.3 (Até o momento o caterpillar só funciona com essa versão do rails, estamos trabalhando nisso)

* no caso de utilizar postgres
gem install pg
gem install activerecord-jdbcpostgresql-adapter

3) Criar projeto

rails nome-projeto
cd nome-projeto

ruby script/generate controller example index

- Configure a rota

map.example(‘example/index’, {:controller => ‘example’, :action => ‘index’})

- Adicionar as dependências das gems no config/environment.rb
config.gem "caterpillar"
config.gem "lportal"

- Configurar config/database.yml
development:
adapter: postgresql
database: lportal
username: postgres
password: postgres
host: 127.0.0.1
timeout: 5000

production:
adapter: jdbcpostgresql
database: lportal
username: postgres
password: postgres
host: 127.0.0.1
encoding: unicode

- Ativar caterpillar

ruby script/generate caterpillar

- No arquivo config/portlets.rb adicione
portlet.container.root = ‘/../Programas/liferay-portal-5.2.3/tomcat-6.0.18/’
portlet.category = ‘Rails-apps’ (ou um nome que você preferir)

- Deploy

* Teste a conexao com:
caterpillar portlets

- Gerar o arquivo warble.rb
warble config

- Adicionar essa configuração no warble.rb
config.gems << "activerecord-jdbcpostgresql-adapter"
config.gems << "lportal"

# Precisa fazer apenas uma vez
caterpillar jar:install (Coloca o portlet genérico que trata as requisições no liferay)

# Sempre que mudar alguma configuracao e for testar a aplicação no liferay
caterpillar xml
caterpillar warble (nesse momento não pode ter nenhuma gem nativa no environment.rb, exemplo pg)

# Utilizado para atualizar os arquivos no container
caterpillar deploy:xml
caterpillar deploy:war

Após realizar os passos acima, inicie o Liferay e acesse a aplicação. Selecione o portlet rails que se encontra na categoria que foi configurada. Pronto, nós temos nosso portlet rails rodando!

Esse foi o primeiro de uma série de posts sobre o assunto. Fiquem no aguardo.

Equipe CFA:
Túlio Ornelas, Pedro Dias, Bruce Rodrigues e Renan Mendes.

Galera,

Quarta passada, assistimos à metade do vídeo sobre JQuery e discutimos um monte! (Tanto que não conseguimos assistir mais que a metade do filme).

Essa quarta, dia 20/jan, das 17:00 às 19:00, vamos terminar de assistir ao video (espero) e acabar de discutir sobre ele.

(Não, não é o filme do urso que vamos assistir, é o de JQuery ;-) )

Em seguida - na outra quarta - iremos resolver algum desafio com JQuery.

Novamente, estão todos convidados! (Só peço que quem vier avise por email ou comentário, pois semana passada quase faltou cadeira :-P )