2007 foi o Ano do Python
A minha linguagem de programação favorita foi a que mais cresceu em 2007, tornando-a segundo o TIOBE e seus fãs a Linguagem do Ano em 2007.
Leio essa notícia em vários blogs atualmente. Para saber mais sobre isso, assine o feed do Planeta PythonBrasil. Um boa leitura!
Powered by ScribeFire.
O Pregão do Laptop Escolar
O XO da OLPC parece que vai perder a parada. O pregão para a compra de 150 mil laptops escolares teve um vencedor: o Mobilis da Positivo Informática. Ela venceu a primeira fase, mas não se sabe ainda se é uma vitória definitiva. Depende de um acordo entre as partes. O Governo quer um preço menor.
Eu estou torcendo pelo XO, entretanto, torço pelo pela idéia como um todo. Espero que os investimentos nessa área não diminuam com os cortes orçamentários.
Links:
Sobre críticas e elogios ao XO da OLPC
Encontro muitas críticas infantis sobre o XO, o famoso laptop de “100 dólares” da OLPC – one laptop per child. Muito dizem que o laptop não presta porque é muito pequeno, não é potente, possui pouca memória e não tem Windows instalado. Em relação a isso dar para perceber que o pessoal não anda lendo mais a respeito do propósito do computador e das novidades tecnológicas a que se destina.
O XO deve ser econômico. Ele não é um laptop somente para a cidade mas também para o campo. Não é computador para classe média ou classe alta, e sim para alunos carentes. Esses computadores estão destinados a lugares distantes, possivelmente sem energia. Esses lugares ainda existem em nosso mundo e até no Brasil, podem crer.
Dizer que as crianças precisam aprender a usar o Windows para entrar no mercado de trabalho é brincadeira. Os laptops são destinados a crianças bem jovens que vão usar o laptop como meio pedagógico para acelerar o aprendizado. O foco não é o mercado de trabalho, mas indiretamente, claro vai contribuir para isso.
Uma matéria interessante para quem quer entender mais um pouco sobre o hardware do XO e sua proposta pode ser encontrada aqui.
Outros links:
Pycon Brasil chegando
A proximidade do evento e certamente sua importância como fator de divulgação da linguagem, foi energia mais que suficiente para escrever em meu blog. O Mosaico tá parado.
Por tudo o que li nos blogs e no PythonBrasil, o evento promete muito. Leio mensalmente a Linux Magazine e certamente deverá aparecer alguma matéria sobre o evento. Afinal, Python é muito usada pelas distribuições do sistema operacional Linux.
Ótimo evento a todos! Estarei no primeiro que for nas terras nordestinas.
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.
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.
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.
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.
