O pessoal gostou da linguagem e achou ela bastante prática. Mas não faltaram as reclamações de sempre:
…blablabla ter que colocar o ‘self’ na declaração do método blablabla…
Ou ainda aquela:
…blablabla bloco de código definido por indentação blablabla…
E tem aquela “inédita” da:
…blablabla SEM TIPAGEM MEU CÓDIGO VAI FICAR TODO BUGADO! blablabla…
Se tipagem reduzisse a quantidade de bugs de um sistema dificilmente uma aplicação Java tinha erro.
Ah… e já ia me esquecendo da famosa:
…blablabla É LENTO!!! blablabla…
Essa repetição de argumentos já está me deixando cansado. Podiam começar a usar alguns argumentos novos para o debate (como o fato da nomenclatura de métodos e classes dos módulos da biblioteca padrão serem todos ‘despadronizados’ ou coisa do tipo).
Mas de todas as que eu ouvi lá a que eu mais amo de paixão é a frase:
Python não serve para desenvolver sistemas grandes.
É… Alguém precisa avisar o pessoal do Google disso…
Acho que uma pessoa menos cabeça-dura/teimosa do que eu já estaria acreditando em tudo isso que foi dito e estaria feliz programando em XML… ops… Java com Struts em algum departamento de TI Dilbertiano me achando o programador mais feliz do mundo por estar “ganhando dinheiro” com isso.
Apesar de ser ainda muito jovem (tá, eu admito que estou com alguns fios de cabelo branco aparecendo e alguns dos fios pretos insistem em se suicidar pulando da minha cabeça) eu programo computadores a bastante tempo. Pra falar a verdade eu programo computadores desde meus 9 anos de idade (nasci em 1977) quando programava em LOGO (aquela da tartaruga) e Basic (MSX e Apple).
Já notaram como nerds são saudosistas? 🙂
Apesar da minha pouca idade eu era um mini-nerd muito disciplinado. Sempre que começava a desenvolver alguma coisa parecia uma máquina de produzir código (e quando eu vi alguns desses códigos recentemente descobri que eu programava muito melhor do que hoje). Sentava diante do meu Expert e começava a ‘fritação’, comia os lanches oferecidos na minha jaula… digo… quarto com uma das mãos enquanto a outra digitava ‘if opc$ = “a” then gosub 10000: rem subrotina foo’…
Nos finais de semana meus colegas do bairro (sim, eu era um nerd com amigos, não me pergunte como eu fazia) iam todos para casa jogar no meu computador. Mas não iam jogar “Kings Valley” da Konami, iam para jogar o ‘superjogo’ feito por mim “ED-209” (inimigo do Robocop) que movimentava “Sprites” e fazia side scrolling… jogo bom mesmo.
Hoje eu não consigo mais essa façanha. Pareço um doente de ‘DDA’. A desculpa que eu dava era a de que eu não tinha tempo. Mas neste exato momento eu tenho tido bastante tempo e mesmo assim não tenho produzido nada.
Posso tentar criar diversas desculpas para esse problema mas a verdade é que minha disciplina foi-se embora a muito tempo e mal consigo segurar um pouquinho dela para fazer um post para esse blog.
Esse tipo de situação faz com que eu sinta uma inveja muito grande (uma inveja sadia daquele tipo que parece muito com admiração) de pessoas como o Gustavo Niemeyer. O Gustavo parece ter um dia de 36 horas para trabalhar. É impressionante a lista de projetos que ele consegue produzir. Ontem ele lançou a versão 1.0 do módulo DateUtils para Python. Isso foi pouco tempo depois dele ter apresentado uma palestra na EuroPython sobre o outro módulo Python para resolução de problemas de restrições que ele também fez. Ele também fez o Smart e o Pybot, tem também o LunaticPython e o … e o … e o …
Não é pra ter inveja? 🙂
Eu não fiz links para os projetos dele porque deu preguiça e porque todos estão listados na página pessoal dele.
Para compensar a total falta de coisas feitas em casa eu tenho feito bastante coisa legal no trabalho. Tenho trabalhado com Python (e C, já que estou fazendo bindings para uma biblioteca feita em C) para fazer com que essa linguagem seja bastante usada na plataforma Maemo.
Já dizia meu pai: ‘Cabeça não pensa, o corpo sofre’. Precisei de um gerador automático de arquivos de definição (.defs) usados pelo codegen do PyGTK para gerar automaticamente os bindings Python para o PyGTK aqui no meu trabalho.
Após uma rápida procura dentro do diretório codegen do PyGTK não achei nada que poderia fazer esse tipo de tarefa e então parti para a ‘ação’ e fui implementando um scriptzinho que fizesse isso.
Hoje me deu um ‘estalo’ e eu resolvi perguntar para o Kiko se ele sabia de algo que fazia isso. Ele me respondeu: ‘codegen/h2def.py’.
Resultado: trabalho perdido ?
De qualquer forma eu usei uma maneira ligeiramente diferente para resolver o mesmo problema.
Acontece que o meu script não está completo ainda (falta parsear estruturas ‘enum’) e estou com pressa para terminar meu trabalho. Como já existe um script pronto para fazer isso vou usá-lo agora e futuramente termino o meu.
Para o caso de eu demorar para voltar ao meu script vou disponibilizá-lo aqui. Se alguém quiser mexer nele, ou, submetê-lo para o pessoal do PyGTK, mande bala.
Hoje eu e o Rudá fizemos o teste definitivo do Python com Pygame no Nokia 770. Testamos ele com o jogo Solarwolf que é um dos joguinhos mais completos no site do Pygame. Enquanto eu preparava ele pra rodar no 770 (eu tive que truncar a imagem que originalmente era 800×600 para que ela coubesse na tela de 800×480) eu pensei: “Isso não vai funcionar. Vai ficar lento toda a vida”.
A boa notícia: não ficou lento! 🙂 A má notícia: O protótipo que a gente tem aqui não está com o som configurado ainda, logo, o jogo ficou mudo.
Particularmente fiquei superfeliz com o resultado. A gente já tem todos os pacotes prontinhos para rodar isso dentro do Scratchbox. Só não disponibilizamos publicamente ainda porque estamos com um probleminha que tá impedindo que a gente se conecte com nosso servidor Web.
Além desse trabalho eu estou fazendo os bindings Python para a biblioteca Hildon da plataforma Maemo. O segredo para isso é gerar uns arquivos com a extensão ‘.defs’ (com sintaxe Scheme) com as definição das APIs da biblioteca em C. Para não ficar fazendo ‘trabalho de macaco’ eu estou fazendo um gerador automático de ‘.defs’. Se funcionar direito eu acho que será útil para o pessoal que desenvolve o PyGTK também.
Não é muito raro ouvir (ver) em alguns sites pessoas dizendo que a comunidade Python é arrogante. Também não é difícil notar que existem talvez umas 3 pessoas que dizem isso. Este post se tornou necessário porque apesar de serem poucos essas pessoas são extremamente ruidosas.
Se o trabalho deles é o de ‘destruir’ a nossa comunidade temos que agir imediatamente para derrubar o mito criado por essas pessoas.
A comunidade Python no Brasil hoje está crescendo num ritmo bom que garante que ela aumente de tamanho sem perder a qualidade, ou seja, estamos crescendo e não inchando.
Para todos os pythonistas brasileiros é importante ter pessoas esforçadas em aprender e a estudar essa ferramenta e não sangue-sugas que simplesmente entram para o time porque é sexy usar uma ‘linguagem alternativa’ ou porque precisam entregar um trabalho para o seu professor e precisam de alguém para fazer o serviço (esse tipo, aliás, não é exclusivo de nossa comunidade).
Algumas das pessoas que propagam que a comunidade Python brasileira é ‘arrogante’ fazem parte dessa minoria que tenta dar uma de espertos para cima da nossa comunidade.
Coisas do tipo “<loser> Ei! faça o meu trabalho de faculdade? <pythonista_arrogante> Não <loser> Nossa! Como vocês são arrogantes!” são menos incomums do que deveriam ser.
Uma outra coisa que também faz com que o clima esquente em nossas listas de discussão é: intolerância. Fico impressionado como as pessoas andam intolerantes. Juntando à essa intolerância a impossibilidade de expressar sentimentos via e-mail e o estrago está feito. Vou ilustrar algo real que aconteceu em nossa lista recentemente em uma discussão que falava sobre a total liberdade que Python dá ao programador e sobre os perigos que isso representava:
Parece coisa de C o programador sabe o que ta fazendo ele
permite fazer qualquer loucura heheh
Uma opinião pessoal interessante, com um “heheh” no final que demonstra claramente que trata-se de uma brincadeira. A resposta para isso foi:
Cuidado com este tipo de comentário. Está sugerindo
programadores em Python não sabe o que está fazendo?
A nossa sorte que a pessoa que mandou a primeira mensagem era uma pessoa legal e não resolveu sair da lista e sair por aí falando que todos os pythonistas agem dessa maneira. Não é legal condenar toda uma comunidade por um equívoco cometido por um dos membros. O pythonista que foi descuidado em sua resposta, por exemplo, é um excelente membro da lista e prontamente responde à todos que solicitam ajuda, mas dessa vez, admito, pisou na bola.
Esse problema também ocorre em diversas outras listas de discussão que eu participo e por isso eu digo e repito à todos que estão lendo isso aqui: Sejam tolerantes em discussões, principalmente nas ocorridas através de mensagens escritas onde a carga emocional não pode ser trasmitida de forma satisfatória.
Uma outra dica para os recém-chegados ao meio do Software Livre em geral: ninguém tem obrigação de te ajudar em nada no universo do Software Livre. As pessoas te ajudarão em solidariedade e no interesse de que a comunidade do Software Livre cresça com pessoas esforçadas. Na comunidade do Software Livre não tem bobos e ‘nerds babões’ como dizem por aí, portanto, não tentem dar uma de espertos pra cima da gente que não vai colar. Demonstre que você já tentou solucionar os seus problemas antes de enviar uma dúvida para uma lista.
E o recado mais importante: Antes de mandar uma mensagem para uma lista de discussões (qualquer uma e não apenas a python-brasil) dê uma lida nesta página para que depois você não fique nos chamando de arrogantes.
Sempre que escrevo sobre algum assunto ‘polêmico’ tenho uma certa tendência a escrever ‘pisando em ovos’. Isso faz com que o que eu escreva fique complicado de se ler. Espero que isso não ocorra agora mas, caso ocorra, peço um pouquinho de paciência para passar pelo texto todo.
O título deste post é um exercício de futurologia. Se eu fosse um milionário eu diria que isso é uma profecia, mas como sou um ‘mortal-comum-ligeiramente-devedor’ digamos que essa história é apenas uma impressão que eu tenho que faz com que minha intuição me avise: a GUI está caindo aos poucos em desuso.
Quem vai ser o algoz das Interfaces Gráficas? A Web.
“Mas Osvaldo, a Web já está aí a um tempão e as GUIs ainda existem. Além disso essa previsão de que a Web iria matar as GUIs já vêm de longa data…”. Ok. Devo admitir que isso é parcialmente certo mas recentemente algumas coisas apareceram na Web que abalaram a crença dos que acreditam nas GUIs: Gmail, Google Maps, Google Suggest e Web Accelerator. O que esses caras tem em comum? Eles surgiram no Google e, com excessão ao Web Accelerator, usam a idéia da tecnologia Ajax.
Esses caras, junto com alguns outros sites espalhados pela Web em páginas que falam sobre Javascript, DHTML, XHTML, DOM, etc, etc e etc, estão mostrando que os navegadores hoje podem fazer coisas que ninguém imaginava a alguns pouquíssimos anos atrás.
Para apimentar ainda mais esta história, recentemente o Google contratou desenvolvedores do Mozilla e do Internet Explorer. Meu chute? Eles vão desenvolver uma suite Office inteira para ser usada via navegador e disponibilizar discos remotos para podermos gravar os nossos arquivos. Além, é claro, de indexá-los para facilitar a nossa busca e para que facilmente anexemos documentos da Rede em nossos trabalhos (essa, sem dúvida, é de fazer até os não-conspiracionistas tremerem, mas… 🙂 ). Neste esquema também teremos mais ASPs (Application Service Providers) pipocando por aí.
A facilidade com que se distribui atualizações de software, o alcance das soluções vendidas, o custo operacional menor (suporte), outras formas de receita (publicidade), e mais outras coisas que certamente os mais espertos já pensaram fazem com que as soluções Web sejam muito mais vantajosas que as atuais aplicações GUI. Com a computação pessoal permitindo a navegação em qualquer lugar em que você esteja e suas aplicações rodando remotamente em algum lugar da Web darão total liberdade a qualquer tecnomaníaco (como eu).
Do lado dos desenvolvedores cada dia mais o desenvolvimento de aplicações Web tem se tornado mais fácil (tem casos até em que desenvolver para Web é mais fácil do que desenvolver software ‘tradicional’). Para confirmar o que eu digo é só ver o Zope, e o Plone com ferramentas como o ArchGenXML. Eu vi uma aplicação sendo desenvolvida em velocidade espantosa em uma apresentação do Fabiano “xiru” em nosso evento em Abril.
Quem serão os responsáveis pela perpetuação das GUIs? Aplicações gráficas mais específicas (CADs, DTPs, etc) e Jogos de computador que exigem alta performance dos equipamentos.
Por isso você, desenvolvedor brasileiro, tente se antecipar à esse movimento e comece a trilhar os caminhos do desenvolvimento Web. Só assim poderemos deixar para trás esse ‘mundinho antiquado’* dos Delphis, Kylixes e Visuais Basics e entrar pra valer no futuro tecnológico mundial.
* Sei que os Delphis, Kylixes e Visuais Basics ainda solucionam vários problemas de empresas brasileiras e que o investimento para se reescrever as centenas de milhões de linhas de códigos dessas plataformas para usar tecnologias mais novas é alto demais. Mas nunca devemos esquecer que no nosso mundo tecnologia ‘velha’ custa caro também e um investimento maior hoje poupará muito dinheiro futuro.
Sei que demorei pra expor as minhas impressões sobre o primeiro evento ‘pythoniano’ realizado no Brasil. A verdade é que eu ainda estava em êxtase.
Foi muito massa. A 1a. PyConBrasil (que ainda era tratada por alguns como PyConDayBrasil) foi fantástica porque mostrou como o nível dos usuários de Python é uma coisa de fazer inveja à muitas outras comunidades.
Também, o que mais poderia ser esperado de figuras como: Rodrigo Senra, Luciano Ramalho, Sidnei da Silva, Fabiano Weimar (xiru), Gustavo Niemeyer, Jean Ferri, Marco André, Luciano Pacheco, Gustavo Barbieri que já são bastante conhecidos por nós através da lista de discussões e com figuras não tão conhecidas por nós mas que deram verdadeiros shows como no caso do Vinícius (que usa Python para cálculo numérico em seu curso de Eng. de Materiais), o João Calligaris (que mostrou Python+Gimp para uma platéia que aparentemente não conhecia essa possibilidade) , Johan Dahlin (que é um dos maiores hackers do universo Gnome e responsável pela manutenção do PyGTK), o Frederico (que a partir de então é a minha prova viva de que é possível aprender Python rapidamente mesmo não sendo um programador), e o Evandro (que mostrou o trabalho que a Async está fazendo com o Stoq e mostrou um pouco de Python no desenvolvimento de ‘aplicações comerciais’).
Foram 2 dias onde não se via pessoas saindo do auditório porque uma palestra ou outra estava ‘chata’. Teve uma presença razoável de pessoas (não lotou mas quase não se via cadeiras vazias também).
Quase todas as palestras foram ‘interativas’ e as pessoas da platéia trocavam idéias com os palestrantes o tempo todo ressaltando ainda mais a competência dos palestrantes que prontamente respondiam à todas as dúvidas.
E a 2a. PyConBrasil?
Você ainda não está se preparando? 🙂 Eu não quero ouvir desculpas esfarrapadas para não ir à 2a. PyConBrasil. Existe uma chance da 2a. conferência também seja em Campinas mas nada impede que a gente converse e tente mudá-la para outro lugar (de forma a criar uma conferência ‘nômade’).
Para todos que ficaram com água na boca e não puderam estar presentes ao evento o pessoal da Unicamp disponibilizou as palestras em stream de vídeo e no PythonBrasil encontra-se os arquivos com a maioria das palestras.
Recentemente, durante o trabalho de escrever o meu livro sobre Python (não, não está pronto e ainda falta muito), me deparei com uma característica que achei superlegal em Python. Essa característica provêm da idéia de que uma string também é uma seqüência tal como listas ou tuplas. Essa característica permite que eu faça coisas como:
>>> a = [1,2,3]
>>> a += "spam"
>>> a
[1, 2, 3, 's', 'p', 'a', 'm']
Quando estava jantando com o pessoal da PyConBrasil (que aliás foi muito massa) fui mostrar pra eles essa característica, mas como não lembrava exatamente o exemplo anterior eu demonstrei conforme abaixo:
>>> a = [1,2,3]
>>> a = a + "spam"
Qual não foi meu espanto quando o resultado obtido foi um:
>>> a = [1,2,3]
>>> a = a + "spam"
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can only concatenate list (not "str") to list
Quando vi isso entendi que o ‘problema’ ocorre porque o operador “+=” é mapeado para o método __iadd__() enquanto que o operador “+ é mapeado para o método __add__”.
Até aí tudo certo. O problema da tal ‘inconsistência’ é que no caso específico dos objetos de listas (list) o método __iadd__() nada mais é do que um apelido para o método extend().
Após algumas discussões com outros pythonistas de alto nível não foi possível chegar a nenhuma conclusão sobre se iss é ou não é um erro de design da linguagem.
No post de hoje veremos em 5 lições como você deve proceder para que seu projeto falhe completamente. Invariavelmente, se você não se empenhar na aplicação das dicas fornecidas aqui é bem provável que você não consiga fazer com que seu projeto falhe mas apenas que tenha um resultado medíocre que é o atraso do cronograma. Por isso, estude todos as lições para que você realmente consiga fazer com que seu projeto falhe.
Esse artigo é antigo e não reflete integralmente a minha opinião. Entretanto ele será mantido aqui por motivos históricos.
Osvaldo Santana Neto
Lição 1 – Analise, analise e depois analise
Isso mesmo. Seu projeto corre o risco de ser um sucesso se você não trabalhar bastante na análise do problema a ser resolvido. Já imaginou se no lugar de analisar você tivesse implementando algo?
Implementar algo é a pior coisa que você pode fazer para que seu projeto falhe.
Se o problema é simples e não demanda muita análise utilize a sua criatividade para aumentar o problema e tentando convencer o usuário (cliente) de que este problema que ele não tem é algo que ele deveria ter.
Lição 2 – Trate o projeto de software da mesma maneira que um engenheiro trata o projeto de uma ponte
Se você tratar o seu projeto como um projeto de software ele tem uma mínima chance de dar certo e isso é algo intolerável para a nossa missão. Faça diferente. Trate o seu projeto de software da mesma maneira que um engenheiro trata do projeto de uma ponte.
Para fazer isso com sucesso auto-denomine-se “Engenheiro de Software”, além de pomposo (já que você não tem um diploma de engenharia, não estudou Cálculo I/II/III/IV e não está registrado no CREA) representa melhor o trabalho que você fará no seu projeto. Isso implica que você terá que abandonar o título de “Desenvolvedor” ou “Programador” porque esses dois caras aí são caras que “desenvolvem” e “programam” e isso é algo que não devemos fazer.
Software como o nome diz é algo “soft” (maleável, leve, suave) se tratarmos ele dessa forma teremos sucesso no projeto e não é isso que a gente quer. Então trate o software como algo “hard” (estático, pesado, duro) e para nos certificarmos de que tudo dará certo (quer dizer, errado) trate ele como algo “hard” e “heavy” (pesado, grande). Para podermos ilustrar a nossa idéia:
Trate o desenvolvimento de um projeto de software como se fosse o projeto de uma ponte.
Nada mais estático e pesado do que uma ponte (o caso da ponte da BR-116 é uma excessão à essa regra).
Engenheiros adoram usar coisas como PMI, Microsoft Project, Primavera, etc. Essas técnicas geram planilhas muito legais com cronogramas e tabelas cheias de informações facilmente geradas em uma planilha eletrônica convencional. Mas uma planilha eletrônica convencional não é reconhecida por PMIs e etc.
Adote a metodologia mais pesada que você conseguir adotar. Uma dica: RUP. Sugira a aquisição da caríssima Suite Rose para que você possa passar dias (ou meses) desenhando quadradinhos e setinhas. Assim vocês terão vários diagramas sexys para mostrar para o cliente em substituição à código implementado e funcionando. A metodologia RUP também adora documentações que é o assunto da próxima lição.
Lição 3 – Documente
Ao gerar documentação você estará dando uma importante contribuição para o insucesso de nosso projeto. Mas quando eu falo de documentação eu não estou falando apenas de um ou outro documento “levemente útil” como um resumo e/ou esboço de um diagrama de classes ou diagrama de ER. Eu estou falando de páginas e mais páginas de especificações, cartões, diagramas UML em sua plenitude (status, use cases, …), planilhas de todos os tipos, manuais e todo o resto que sua imaginação permitir. Lembre-se:
Enquanto você documenta você não implementa, logo, fracassa.
A documentação é uma boa técnica para que nosso projeto falhe porque além de você perder tempo fazendo ela no começo do projeto você vai ter que perder esse tempo todo novamente no término do projeto para “atualizar” a documentação (coloquei “atualizar” entre aspas porque o “atualizar” alí significa jogar tudo fora e fazer novamente).
Uma dica adicional nessa lição é: formato é muito mais importante que informação, portanto, deixe o designer que existe em você aflorar durante a confecção desta documentação.
Lição 4 – Fale “buzzwordês”
“O beans das business class precisam passar por um deploy” é uma frase que contribui muito mais que “As classes de negócio da camada model precisam ser entregues” para o insucesso do projeto, portanto, extenda seu buzzwordês. Alguns bons pontos de partida para isso é ir nos sites da IBM e Sun (principalmente a parte Java) e ler tudo que fizer referência à J2EE, e-business, etc. (dê uma olhada especial no produto Websphere da IBM… aquilo é um clássico do buzzwordês).
Essa lição aparentemente não apresenta nada prático que contribua para o não-andamento do nosso projeto mas acredite ela é fundamental para que nosso projeto fracasse.
Lição 5 – Adote o hype
Eu tenho uma paixão especial por essa lição. É a que eu tenho mais prazer em ensinar. A minha definição de hype é: tudo aquilo que não tem nada de inovador e mesmo assim promete resolver todos os tipos de problema. Os hypes são criados por pessoas de marketing e pessoas de marketing raramente sabem desenvolver software, logo, se você ‘comprar’ tudo o que eles te vendem é grande a chance de que nosso projeto fracasse e nossa tarefa se torne um sucesso.
Em alguns casos (raros) o hype pode até não ser a solução para todos os problemas, mas soluciona muito bem algum tipo muito específico de problema (mesmo que não tenha nada de inovador em sua idéia), portanto, cuidado com casos do tipo “vou usar XML para gravar uma informação estruturada num formato padrão texto” porque é exatamente pra isso que XML serve e nesse caso ele se torna útil (blerg!). Use XML em coisas para as quais ele não foi pensado: linguagem de query, linguagem de programação, arquivos pequenos de configuração, etc.
Prefira usar o “Enterprise jXML .NET” para fazer o seu trabalho do que usar algo que seja simples e funcional. Coisas como J2EE, EJB, JMS, etc são ricos em hypes, portanto, fique antenado à essas coisas.
Conclusão
É isso aí, com o passar do tempo eu vou passando algumas lições do “Curso de Projetos Fracassados” para que você sempre esteja por dentro das boas práticas para o insucesso de seu projeto.
