Publicado em linux, open source, python, turbogears

TurboGears 2: solução de problemas durante a instalação

Pediram-me para documentar a instalação do TurboGears 2. Vocês podem encontrar os passos para a instalação aqui.

O restante deste post é sobre como solucionar certos problemas. Então, se você seguiu a documentação oficial e não teve problemas não precisa mais ler este post.

É bom salientar que fiz a instalação no Ubuntu Linux.

Installing TurboGears 2 from Source

Nesse ponto, quando vocês forem instalar o tg2 com python setup.py develop, vocês não encontrarão o arquivo setup.py. Ocorre que agora o tg2 usa o paver como instalador. Ou seja, documentação desatualizada. Na raiz de tg2 execute sudo paver develop.

Pode ser que durante o download das dependências do tgdev, não seja encontrado a versão 0.8.7dev do ToscaWidgets. Se este for o caso, é melhor você esperar um tempo para eles disponibilizarem-na e então sincronize a cópia de trabalho com svn update. Depois, execute novamente sudo python setup.py develop.

Concluídas as demandas, você já pode brincar com o TurboGears 2. Comece pelo Wiki em 20 minutos.

Estou querendo instalar o TG2 no Windows, então os problemas que possa encontrar vou colocar como comentário aqui.

Anúncios
Publicado em desenvolvimento, open source, python, turbogears

Primeiro contato com TurboGears 2

Como o Twitter não está muito bem, vai ser por aqui mesmo que informo aos amigos e colegas pythonistas que tive pela primeira vez contato com o TurboGears 2 hoje. Acabei de fazer o exemplo da Wiki.

Aos poucos, devo começar a me aprofundar no uso dele, uma vez que estamos pensando em adotar o framework para o desenvolvimento de um projeto. Queremos que nossa aplicação acompanhe o desenvolvimento do TurboGears, mesmo que isso seja arriscado.

Tive um razoável trabalho para instalá-lo na minha máquina. O trabalho não se deveu ao fato de tê-lo de obter via Subversion, mas sim porque alguns pacotes não estavam sendo encontrados pelo easy_install. Também precisei usar o Paver para baixar umas dependências. Isso a documentação de instalação não explicou. Devo fazer a instalação também no notebook do Stênio. Não anotei nada, espero conseguir.

Apesar dele manter a API bastante semelhante ao TurboGears 1, há componentes novos. A curiosidade foi aguçada por conta disso. Estava tão por fora, que somente agora fiquei sabendo sobre o Paver, criado pelo próprio Kevin Dangoor. Parece-me um melhoramento sobre o processo de instalação/distribuição/empacotamento.

Deixemos para outros posts demais conclusões sobre o TG2.

Publicado em colaboração, desenvolvimento, open source, python, turbogears

TurboGears: a espera

Devido a existência do projeto de desenvolvimento do Turbogears 2, decidi fazer uma pausa nos estudos e casos de uso sobre esta framework. O Turbogears 2 é um reprojeto visando adotar o WSGI como base para a componentização e reusabilidade na arquitetura.

WSGI é um padrão já adotado largamente na comunidade Python. Ele facilita bastante o reuso de código em aplicações web, principalmente. A equipe de desenvolvimento resolveu adotar o núcleo do Pylons 1.0 para pular etapas, uma vez que este já adotava o WSGI, inclusive adotava o Paste para facilitar a configuração. Vale ressaltar que eu fico maravilhado com a tríplice setuptools + wsgi + paste.

Essa mudança é um ponto positivo mas que me levou a parar um tempo de escrever sobre a framework aqui no blog. A sensação é que ela está no limbo e o Django continua ganhando novos adeptos. Verdade que este limbo é bem produtivo e tenho a sensação de um retorno ao mercado ainda este ano.

Então, quando tivermos lançamentos oficiais e documentação sobre o Turbogears 2, estarei novamente estudando e escrevendo aplicações de exemplo e divulgando minhas experiências por aqui.

Um pouco do meu tempo para todo mundo.

Powered by ScribeFire.

Publicado em desenvolvimento, linguagens, linux, python, turbogears

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!

Publicado em desenvolvimento, open source, python, turbogears

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.

Publicado em desenvolvimento, python, turbogears

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.

Publicado em desenvolvimento, open source, python, turbogears

Notícias recentes sobre o TurboGears

O Planet TurboGears é pouco movimentado mas hoje apareceram dois posts importantes, pois tratam do futuro do framework. O primeiro que li foi o post do Mark Ramm, resumindo os acontecimentos e decisões tomadas num sprint recente.

Logo de cara fiquei surpreso com uma experiência que fizeram. Um projeto de integração do TurboGears com o Pylons. Pelo visto, foi um sucesso. Tem todo o jeito de ser a infraestrutura para a versão 2 do framework. O objetivo do experimento foi encontrar uma maneira do framework ser mais flexível e fácil de manter. Nada mais justo. Dangoor diria também, enxuto.

O TurboGears 1.1 será lançado em poucas semanas. O motor de template será o Genshi e o ORM por sua vez será o SQLAlchemy. Eu já testei o Genshi e ele ganha de imediato nas mensagens de erro mais legíveis. O SQLAlchemy, como muitos sabem, é robusto (mas o SQLObject é mais simples e fácil de aprender) e torna-se a escolha certa. Parece que pode haver ainda uma versão 1.2 só para suportar o CherryPy 3.

Mark Ramm ainda informa que a versão 2 do citado framework ganhará novos recursos como caching e outras formas de melhorar o desempenho. O Routes estará integrado ao TurboGears, o que trará certamente URLs mais flexíveis.

O post de Kevin Dangoor comenta o sprint do último final de semana em que eles trabalharam com código especificadamente para o TurboGears 2. Diz tratar-se de uma volta às raízes porque seu objetivo é fazer do TG um framework com um pequena quantidade de código, basicamente para orquestrar diversas bibliotecas. Assim era na versão 0.5.

O criador do framework ainda diz estar entusiamado com a atividade e espera ter alguma coisa pronta em algumas meses.

Consegue-se perceber que a comunidade de desenvolvedores do TurboGears ainda é uma das mais ativas. Já o framework Pylons, chama atenção porque ela foi criada como um estudo de caso para Paste, Setuptools e WSGI. Estes três nomes estão melhorando as ferramentas e o jeito de desenvolver para web.

Powered by ScribeFire.