Gestão do Tempo Além dos Cronogramas 5
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
Desenvolvimento de portlets com Rails - parte 2
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.
DojoSEA: quarta, e novo 7
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!
DojoSEA: vai explodir! 5
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… :-(