O tempo e outras coisas

Ultimamente voltei a ficar ocupado mais que o normal. Envolvido num projeto à tarde, não posso usar um tempo maior para meus projetos em Python e Rails, o que pode me levar a escrever menos aqui. Possivelmente com menos qualidade.

Não sei se cheguei a comentar em algum post, mas há algum tempo estou desenvolvendo novamente em Java. Estamos usando Struts 2, Spring e a boa IDE Eclipse. Tá bacana, mas sinceramente, quando você conhece outras coisas, tais como um framework TurboGears ou Rails, sente a diferença de produtividade. É chato envolver-se em projetos onde a produtividade é baixa.

O framework Struts 2 é notadamente mais produtivo que o seu antecessor. Usa a filosofia “Convenção sobre Configuração”, amplamente conhecida na comunidade Ruby, agora espalhando-se por outros “mundos”. Entretanto, sua documentação ainda é pobre, algumas coisas não funcionam como o esperado. Não seria necessário descrever um problema que estou tendo aqui, mas como estou preso nele, não há jeito. No Struts 2, para validar campos de formulários, basta que criemos um arquivo com o nome convencionado NomeAction-validation.xml. Isso é bacana quando há somente uma ação a ser executada por Action. Não é o meu caso. Meus actions possuem vários métodos. Nem todos os métodos são posteriores ao envio de campos de formulário, além de métodos que recebem formulários diferentes.

Segundo a documentação, você pode usar o padrão NomeAction-alias-validation.xml para mapear o arquivo de validação a um “action name”, digamos UsuarioAction-salvar-validation.xml. Porém, isso não está funcionando. O que me faz perder tempo, ou seguir adiante até que encontremos como fazer isso prestar.

As reclamações sobre Java são muitas. É bastante difícil defender essa linguagem. Como argumentar com um desenvolvedor Delphi que eu não consigo implementar rapidamente um funcionalidade que ele é capaz de concluir em poucas horas? É mais fácil esconder isso num ambiente onde só exista Java. Não é o meu caso. Convivemos com aplicações em PHP, Delphi, VB, ASP, etc. Entre fazer algo urgente em Java ou Delphi, estão escolhendo o último. Porém, há mais programadores livres em Java. Os outros estão envolvidos com o legado.

Depois de alguns anos desenvolvendo profissionalmente em Java, aprendi que para ser mais produtivo, devemos procurar sempre o melhor modelo arquitetural, depois manter-se nele. No começo, nosso modelo é sempre desorganizado e improdutivo. Mesmo que usemos padrões de projeto e de arquitetura reconhecidíssimos, trabalhamos ele incorretamente. Muitas vezes usamos padrões desnecessariamente.

Antigamente, ao implementar o modelo de camadas em Struts, como Action -> BO -> DAO, a camada de regra de negócio (BO) e os DAOS possuiam interfaces. Mesmo sabendo que isso não seria preciso, colocávamos porque fazia parte do jeito do javista programar. Aumentávamos gratuitamente o número de coisas a fazer. Hoje, quando sabemos que não vamos largar uma tecnologia, ignoramo o uso de interfaces. Se algum dia (improvável) precisar delas, eu refatoro. O Eclipse esta aí para isso.

Estou aprendendo a trabalhar simples, como os antigos programadores faziam e uma nova safra de programadores estão fazendo. Estou saindo da educação javista. Aprendo muito com outras comunidades: desenvolvedores do mundo Linux, Ruby e Python me ajudaram a ser um programador um pouco melhor. Claro que Java trouxe para mim vários ensinamentos utéis que vou levar comigo.

Espero que os defensores ferrenhos de uma linguagem, qualquer que seja, não fiquem restritos somente a uma linguagem. Uma linguagem não serve perfeitamente para tudo. Ñão perca tempo em teimosia. Podemos usar várias linguagens dentro de nossas empresas e órgãos.

Carpem Diem!

Usando ToscaWidgets

Já comecei a usar os widgets no projeto Ferlons por meio da distribuição twAjaxTools que está sendo desenvolvida pelo pessoal do TurboGears. Eles implementaram basicamente os mesmos widgets do TG, no entanto implementados sobre o framework ToscaWidgets. Essa distribuição, twAjaxTools, como o próprio nome explicita, possui componentes Ajax, mas nem sequer dei uma olhada. Eu queria, na verdade uma das dependências dessa distribuição que é twForms.

Tá faltando agora ver como fazer as validações (acho que só resta mostrar as mensagens) e como usar o pacote elementtree para criar meus hiperlinks para os datagrids que não funciona como eu esperava.

O link para o projeto do Ferlons.

Powered by ScribeFire.

Vergonha do Pan: A torcida

Sinceramente, que torcida mal educada essa nossa, hein?

Vaiaram o Presidente da República (para toda a América ver e ouvir, incluindo aí o Hugo Chavez), vaiaram atletas estrangeiros que também trabalham duro e precisam de concentração, além de desconcentrar atletas brasileiros com muito barulho no momento errado. Cansei de ver isso nas apresentações de ginástica olímpica.

Lamentável.

Powered by ScribeFire.

Widgets do TurboGears fazem falta no Pylons

TurboGears até o momento é o framework em Python mais produtivo com que trabalhei. Isso devido, em minha opinião, a duas coisas: à simplicidade do SQLObject e aos Widgets.

Graças a estes dois componentes, eu consegui implementar o TGBolão em poucos dias. Não vou negar que a reduzida quantidade de formulários ajudou no tempo de conclusão do mesmo. O ganho veio mesmo no momento de gerar as listas nas páginas. Listas de grupos, de seleções, participantes do bolão, apostas, etc. O objeto DataGrid é sensacional. O módulo elementtree era muito útil na hora de colocar hiperlinks e imagens nas linhas do datagrid. Muito fácil.

Eu tento evitar a todo custo fazer os formulários “no braço”. Com o objeto TableForm não tive muitos problemas para criá-los. Junte-se a isso a biblioteca FormEncode e você tem a validação dos campos também.

Pensando nessa produtividade, vou ler sobre o ToscaWidgets antes de tentar usá-lo no Ferlons (minha aplicação para testar o potencial do Pylons). Quero senti a produtividade dele em relação aos Widgets do TurboGears. Até o momento só usei FormEncode.

Não posso esquecer que um ORM ajuda nas consultas que envolvem relacionamento de tabelas/objetos. As regras de negócios ficam mais intuitivas quando vamos implementá-las.

Os comentários que fiz sobre os Widgets e SQLObject foram compreendidos na prática. Muitas vezes ficamos na defensiva quando se trata de coisas desconhecidas, de coisas que somente uma minoria está usando. Sabendo disso, tente, teste e comente com a gente.

Powered by ScribeFire.

Parece besteira comentar …

Parece besteira comentar mas ontem (faz pouco mais de meia hora) fui atrás do Orkut da Jade Barbosa. Fiquei impressionado com a quantidade de recados (scraps) que ela recebia por minuto! Poderia até dizer segundos

Só para terem uma idéia (às 00:32 do dia 18) vejam a quantidade: 50638 recados. Então daqui a um minuto (00:33): 50684. Parece besteira comentar, mas também sou fã da garota.

Powered by ScribeFire.

Pylons: conhecendo aplicando

Escrevi para o Kodumaro um post sobre uma pequena aplicação de controle de férias de funcionários que está sendo desenvolvida em Pylons. A maior parte do texto é a análise de requisitos.

Powered by ScribeFire.

Storm: ORM da Canonical

Estão querendo conhecer mais um ORM em Python? A Canonical liberou como LGPL seu ORM chamado Storm.

Powered by ScribeFire.

Piauí Pop 2007

Para quem indagou o meu sumiço da Internet durante o final de semana, saiba que fui ao Piauí Pop, o maior evento da música em nosso estado. Bandas locais, regionais e nacionais agitaram durante três noites. Rock, Reggae, música eletrônica e música regional estavam lá para serem curtidas por todas as tribos.

Particularmente, gostei do show dos Engenheiros do Hawaii, Lulu Santos e Pitty. Perdi o show de bandas como O Rappa, Charlie Brown Jr. e Bíquini Cavadão. Foi super divertido porém o cansaço que senti foi demais. Tá na hora de criar vergonha e voltar a execitar-me.

Poder da Web 2.0

Visitando o recentemente lançado Planeta Django Brasil, encontrei um post sobre o site Vericia. Gostei do que li. Os desenvolvedores fizeram uso excelente dos recursos disponíveis na Internet. A essência da Web 2.0, a facilidade na troca de informações entre aplicações e sites, foi muito bem usada.

Não posso deixar de citar que o site foi desenvolvido em Python usando o framework Django. Python é produtividade. Parabéns!

Powered by ScribeFire.

Resultado do ShoppCamp 2

As coisas realmente estão funcionando. Percebo claramente que o pessoal que participa desses encontros estão dispostos não só a trabalhar com Ruby on Rails, como também mostrar isso para as outras pessoas.

O grupo então tem uma razão de existir. Mostrar que desenvolver voltou a ser simples, que não é necessário processos pesados para tudo, padrões de projeto sendo usado sem necessidade, que preconceito com linguagens dinâmicas é besteira, e etcetera, etcetera, e etc.

Além de conhecer novas pessoas e rever um colega de faculdade, eu votei no logotipo do agregador de blogs, Therminal. Espero que seja um sucesso. O Elias Jr levou um notebook e fez toda uma apresentação para mostrar os diversos logotipos. Assim que possível eu mostro a figura.

Definimos o nome para a comunidade: Piauí on Rails. A lista do grupo continua sendo Rails-PI.

Falou-se ainda sobre o InfoCEFET, sobre quando as camisas saem, e sobre a possibilidade de criarmos um evento sobre Rails.

Acredito que depois de mais algum tempo, a turma toda ganhando experiência com a linguagem Ruby e o framework Rails, tenhamos demonstrações de aplicações, sprints (possivelmente do Therminal) e eventos.

Ainda é cedo para saber que impacto nossa comunidade pode causar no cenário local. Só podemos esperar para ver o que virá a seguir.

Powered by ScribeFire.