Publicado em desenvolvimento, mobile, python

Idéia exploratória

Uma boa idéia me surgiu agora, útil para o momento e ótima pedida para iniciar a exploração no mundo da programação de dispositivos Nokia que usam o sistema operacional Maemo: um rolador de dados.

Bobo, né? Inclusive, acho que já existe um. Mas é diferente do que eu estou pensando.

Gostaria que a tela do aplicativo mostrasse um quadrado com todos os tipos de dados usados no RPG D&D ou seja, os de 4, 6, 8, 10, 12 e 20 faces. E mais três botões: para o sinal de mais, o de menos e o de igual.

Ao apertar um dos dados ele saberá que quero jogar com ele. Ele esperará eu apertar no sinal de igual para a operação randômica executar. Os sinais servem para aumentar ou diminuir o que resultar do dado. Cada vez que eu apertar num deles incrementa-se ou descrementa-se em um.

Logicamente vou escrever esse aplicativo em Python. Vamos ver se tenho a sorte e produtividade de terminá-lo ainda neste final de semana. Quando concluir, posto por aqui.

Anúncios
Publicado em desenvolvimento, python

Comunidade de Jogadores e Desportistas

O Mosaico Livre é essencialmente um blog sobre programação, engenharia de software, software livre. Ultimamente venho negligenciando esta essência. É como se tivesse perdido o rumo.

O barco, no entanto, deve seguir seu rumo correto.

Já há algum tempo, por curiosidade, li alguns tutoriais e assistir alguns vídeos sobre o Google App Engine, uma plataforma para desenvolver aplicações web que podem usar a infraestrutura do Google. Ou seja, podemos hospedar nossas aplicações nos servidores do Google.

O Google App Engine é implementado em Python. Um fator importante para que eu rapidamente pudesse desenvolver alguma coisa. Logo será possível usar outras linguagens. Até lá o interesse em aprender Python continuará.

E como Python cresceu desde 1999, o ano em que comecei a programar nesta linguagem! Ela já está entre as linguagens modernas mais comentadas. A falta de uma empresa forte que a utilizasse ou pelo menos incentivasse seu uso era um dos motivos para as pessoas não quererem conhecê-la. O Google mudou isso.

Atualmente desenvolvo uma aplicação para Google App Engine. Na verdade, é um portal para concentrar informações sobre esportes e jogos em geral, seja amador ou profissional. Um local onde o pessoal possa conhecer outros praticantes. Por exemplo, sinto necessidade de conhecer pessoas na minha cidade que joguem Go, um jogo de tabuleiro difundido no oriente, mas pouco por aqui. No site, posso informar os jogos que pratico. Quem tiver interessado em jogar comigo, pode enviar um e-mail. Depois, podemos informar no site o local onde jogaremos para que outras pessoas possam comparecer para apreciar a partida.

É raro encontrar algum portal da imprensa que dedique um espaço a esportes com poucos praticantes. A minha idéia é preencher esta lacuna.

Assim que eu tiver terminado, passo o endereço para vocês.

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 desenvolvimento, python

Sistemas de Controle de Versão em Python

Um amigo, Stênio, e eu conversávamos sobre um projeto secreto (o Google não pode saber) que ele tem em mente. Pretendemos implementá-lo em Python. Coube a idéia da escolha do controle de versões ao Stênio e ele disse que gostaria de experimentar o Mercurial. Isso por ele ser descentralizado e ter uma grande variedade de ferramentas. A referida característica faz parte dos sistemas de controle de versões chamados distribuídos, tais como o Monotone e o Git. Aliás, segundo li, o Mercurial e o Git seguem as idéias do Monotone.

Um fato importante a citar: o Git foi inicialmente desenvolvido pelo próprio Linus Torvalds para substituir uma solução proprietária, o BitKeeper, na tarefa de ser o repositório da árvore do kernel Linux.

O Mercurial e o Bazaar são exemplos recentes de controles de versões distribuídos desenvolvidos em Python. O Bazaar é utilizado pela Canonical, a empresa responsável pela distribuição Ubuntu, que aliás, sou um dos usuários satisfeitos. Pensei até em adotar o Bazaar em nosso projeto, mas em consideração ao amigo, ficamos mesmo com o Mercurial.

Aqui no trabalho, usamos o Subversion, o já tradicional controle de versões que veio a substituir o CVS na importante tarefa de versionar e centralizar o acesso ao código-fonte dos projetos.

Gostaria que esse post servisse também para os leitores-programadores a considerarem o uso de um sistema de controle de versões, mesmo para seus projetos caseiros. Aos programadores Python, considerem o uso do Bazaar e Mercurial, em especial.

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.