A GUI está ‘morta’

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.

Nokia 770

Como vocês devem ter acompanhado nos últimos dias a Nokia anunciou o lançamento do Nokia 770. Nada demais até aí exceto pelo fato de ser uma plataforma totalmente nova da Nokia. Esse dispositivo também não será um celular e isso é uma outra novidade.

Além dessas novidades existe uma outra que eu acho que é a mais importante de todas. A plataforma. O Nokia 770 vai rodar com a plataforma Maemo (www.maemo.org) que é totalmente baseada em software Open Source. Isso significa que dentro daquele ‘aparelhinho’ alí vai bater um coração Linux com um servidor X e aplicações baseadas em uma leve variante de Gtk. Perfeito, não é? Quase.

Para desenvolver nessa plataforma é necessário usar linguagem C e programar em C é complicado. Para resolver esse problema existe uma alternativa: portar uma outra linguagem para ser usado na plataforma Maemo. Essa alternativa nos leva a outro problema que é: qual linguagem?

Preciso dizer que linguagem eu escolheria para ser a principal ferramenta de desenvolvimento para Maemo? 🙂

Eu e meu amigo Rudá estamos trabalhando nisso e a nossa maior briga tem sido com o tamanho do Python (juntamente com PyGtk + PyGame). Nossa meta é colocar isso tudo aí em 5MB e hoje temos só o Python (já enxuto) ocupando 2.5M.

Se vocês tiverem dicas/sugestões de como diminuir o tamanho das coisas podem colocar aqui nos comentários ou envie para a python-brasil.

Ah! E já liberamos o primeiro release:

PyConBrasil

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.

Nem tudo é perfeito

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.

Mais sobre essa discussão pode ser visto em:

http://thread.gmane.org/gmane.comp.python.brasil/8755

Democracia não funciona

Sim! Eu voltei! 🙂

Conforme prometido irei comentar aqui porque acho que a democracia não funciona. Os ‘democratas’ de plantão certamente ficarão horrorizados com esse tópico aí em cima e para que não venham queimar bandeiras e fazerem protestos pró-democracia na frente de minha casa vou explicar detalhadamente o que eu quero dizer com isso.

Eu adoro poder votar em meus candidatos, acompanho política, tenho um partido do coração e respeito as diferenças entre as opiniões. Nada mais democrático que isso, não? Pois é. Eu gosto da democracia e acho que para um país como o Brasil a democracia é o menos-pior dos sistemas.

Mas de maneira incrível a mesma democracia que garante que todos os interesses da população sejam sempre não-contrariados também é a democracia que ‘freia’ a evolução. A democracia complica a evolução porque a evolução implica em mudanças e mudanças sempre incomodam grupos que estão satisfeitos com a situação atual.

Quando falamos de tecnologia estamos tratando de um assunto que evolui numa velocidade tão grande que as pessoas ‘de fora’ dessa área costumam chamar essas evoluções de ‘revoluções’.

Ok. Trazendo essas coisas para o nosso mundo-real e mais especificamente para o universo do Software Livre podemos notar que os projetos de maior sucesso do mundo estão sob a tutela de algum ‘ditador’.

É o caso do Linux que segue a trilha de Linus Torvalds, o Mono/Gnome que acompanha o Miguel de Icaza e alguns outros casos por aí. Do outro lado das ‘ditaduras’ está a democracia. É o caso do projeto Debian que é, na minha opinião, o projeto que melhor funciona no modelo democrático de gestão. Pois bem, acredito que deva fazer mais de anos que o projeto Debian não lança um release stable de sua distribuição (apesar de saber que a versão unstable do Debian costuma ser muito melhor que versões considerada estáveis de outras distribuições não bem esse o ponto que quero discutir neste post).

O JCP é outro exemplo de democracia. Essa democracia quase que ‘pregou uma peça’ na plataforma Java fazendo com que o Java 1.5 (Tiger) chegasse apenas muito depois do C# da plataforma .NET da Microsoft que, de forma ditatorial, construiu uma excelente linguagem de programação que possuia todas as funcionalidades disponíveis em Java (a linguagem, não a plataforma) e mais algumas outras de muita utilidade que não estavam disponíveis em Java.

Em Python nós temos um ditador. O nome dele é Guido van Rossum. É ele quem veta ou ‘sanciona’ as alterações na linguagem. Ele ganhou esse direito porque ele é a pessoa que tem em mente o ‘alvo’ (target) da linguagem Python. Ele é um ditador ‘benevolente’ porque ele permite que todos dêem sugestões sobre funcionalidades que Python deve ter ele não ‘prende nem manda matar’ quem discorda dele e quando confrontado com bons argumentos ele tranquilamente os aceita.

Isso faz dele uma pessoa com muitos méritos e a partir da palavra ‘mérito’ que chego ao modelo que eu acho perfeito: meritocracia.

Infelizmente numa escala maior (como no Brasil) é muito difícil implementar uma meritocracia.

Se esse Python fosse meu…

Sou um cara apaixonado por Python.

Apesar da aparente redundância dessa afirmação em um blog que se chama “Pythonologia” e escrito por um cara que faz propaganda de Python até pra sorveteiro. Mas eu prefiro ser redundante à não ser compreendido.

O post de hoje tem relação com algumas opiniões pessoais sobre coisas que eu gostaria que fossem diferentes em Python. Evidentemente que considero o GvR muito mais competente para definir uma linguagem de programação do que o Osvaldo Santana Neto (eu). E se algum dia eu tivesse competência tão grande e fosse criar a minha “linguagem de programação ideal” ao final do trabalho eu teria algo muito parecido com Python (ou Boo).

Existem também aquelas características ‘polêmicas’ em Python que a tornam tão especial.

Indentação (ou endentação? (ou identação? (ou edentação?)))

Essa é uma das características polêmicas de Python. Adicionar função sintática à indentação em Python foi uma sacada de gênio do GvR. Os benefícios proporcionados por essa prática são fantásticos. Particularmente o que mais gosto é o de que você fica ‘desestimulado’ a construir blocos de códigos muito longos porque com eles você se ‘perderia’ no código facilmente, já que é comum um editor de textos não exibir mais do que 50 linhas de textos na tela.

Mas com o bônus vem o ônus: configure seu editor de textos para trabalhar com identação com “<tab>” e abra um código de terceiro cuja indentação é feita com “espaços” e dê manutenção nesse código. Você vai tomar uma semana de “Syntax error” na tela.

Não gosto de linguagens que acrescente dependências de ferramentas externas para se extrair todo o seu potencial. Por sorte até os mais antigos editores de textos costumam permitir uma boa configuração de “Tabs / Espaços / Indentação”.

Esse é o ônus da função sintática da indentação em Python. Mas na minha linguagem eu pagaria esse preço sem pensar 2 vezes.

self…

Qual programador OO que nunca torceu o nariz quando teve que declarar o “self” na definição do método? Eu torci (pra falar a verdade ainda torço… sou péssimo digitador e vivo escrevendo “selg” no lugar).

A inclusão do self na definição de um método foi uma ‘decisão de projeto’ do GvR(?). Assim como outras decisões em outros projetos no mundo nem todas elas possuem fundamentos fortes e sólidos. O parâmetro “self” existe “porque sim”.

Alguns afirmam que é por causa do “The Zen of Python” (tente “import this” no prompt do Python) que diz em um de seus ‘versos’: “Explicit is better than implicit” (Explícito é melhor que implícito). Dessa forma dizer explicitamente que ‘self’ vem por parâmetro seria algo justificável.

Eu acho esse argumento questionável. Mas ele existe.

Se eu fosse dono da minha linguagem ela não receberia “self” como parâmetro do método. Mas receber “self” como parâmetro também não torna uma linguagem de programação ruim.

Em Boo o “self” não é necessário.

Tipagem Dinâmica

Prestem atenção quando falarem sobre a tipagem de Python para que não surjam equívocos. Python é uma linguagem de “tipagem forte e dinâmica” (oposto de fraca e estática).

Minha linguagem de programação seria exatamente igual à Python hoje. E ainda não tenho opinião formada sobre as idéias de tipagem opcional que estão circulando por aí com as discussões para o Python3000 que é algo diferente dos conceitos de tipagem por inferência existentes em Boo.

Mas devo admitir que tenho simpatia por conceitos como o Duck Typing, as Interfaces e os Protocols.

@decorators

Não gostei dessa sintaxe logo de cara. Fiquei horrorizado com essa “@” aí. Não gosto de linguagens que usem muitos símbolos (hint: Perl). Pra mim, quanto mais próximo à linguagem humana o código se parecer melhor.

Não gostei dessa sintaxe, mas ao usá-la eu fui obrigado à admitir que ela é superprática e meu voto que antes era “-1” foi para “0” para a sintaxe (sim, porque o conceito de decorator é legal e já existia na linguagem).

A minha sintaxe favorita era a:

def foo(bla) [dec1, dec2]:
   ...

mas ela não foi escolhida porque em casos (quase que inexistentes) de muitos decoradores na definição da função o código ficava muito poluído.

Em Boo a sintaxe escolhida foi:

[dec1, dec2]
def foo(bla):
  ...

Que também é boa mas é incompatível com uma construção Python válida como esta (Bamboo, se eu estiver errado me corrija):

[funcao_falsa, funcao_verdadeira][a==1]()

… e por esta razão ela não foi considerada.

Módulos e nomenclatura

Em uma conversa com o Luciano Ramalho ele me disse que os nomes de funções builtin, módulos e classes em Python deveriam seguir um padrão para facilitar o ensino e para facilitar a vida de pessoas que não tem memória para ficar armazenando nomes estranhos (como eu).

Eu concordo com ele principalmente se levarmos em consideração os módulos da biblioteca padrão do Python nas quais umas usam atributos com “nomesassim” e outras usam “nomesAssim” (existem também aquelas que usam “nomes_assim”).

Se não fosse o prompt interativo de Python com seu ‘autocompletion’ a vida de um desenvolvedor Python seria muito difícil por essa razão.

Portanto, em minha linguagem os nomes de métodos, módulos e classes da biblioteca padrão seguiriam normas ‘rígidas’ de nomenclatura.

Conclusão

Acho que vocês conseguiram ver que Python não é perfeita. Aliás, nunca deve dizer isso. Python é apenas uma excelente linguagem de programação (assim como Boo também é) e como tal merece ser divulgada e o seu uso também deve ser estimulado para que mais pessoas lutem para que ela melhore e, quem sabe um dia, essa tal de ‘perfeição’ não chega?

Software Bom e Software Livre

Alguns de meus amigos conhecem bem a minha forma de pensar sobre o assunto “Software Livre”. Eles sabem que eu sou um defensor ferrenho do Software Livre e tenho total certeza que todos os tipos de software podem ser livres (muitos desses amigos não concordam com essa parte da minha opinião).

Mas é importante notar a sutileza da palavra “pode” no parágrafo anterior. Ela significa “pode” mesmo e não “deve” porque neste caso eu estaria destruindo a liberdade do autor do software. Sim, o autor do software tem que ter a liberdade de escolher a forma que ele irá oferecer sua obra aos seus usuários. A única coisa que eu posso fazer com relação a isso é tentar convencê-lo de que é melhor pra ele distribuir a sua obra como um software livre.

Neste ponto eu chego a uma outra parte da minha opinião pessoal sobre software: Eu gosto de software bom muito mais do que de software livre. Tá, e como eu defino um software bom? Com um conjunto de características com pesos diferentes.

A principal característica que procuro em um software é flexibilidade. Depois disso procuro por funcionalidade, seguido por usabilidade e finalmente: licença de uso. Eu considero a licença de uso porque considero que o uso de software em desacordo com a sua licença é um desrespeito à seu autor (seja ele pessoa ou empresa) e adquirir a licença de alguns tipos de software é algo que não é viável financeiramente.

Mas seguindo essa linha de raciocínio você vai conseguir entender porque que, mesmo eu sendo um ferrenho defensor de software livre, muitas vezes você irá me ver usando software proprietário. Mas poderá ver também que esse software proprietário que estou usando atende aos requisitos citados acima.

Um exemplo do que eu digo é o Mac OS X da Apple. Ele é um software proprietário construido sobre um software com licença open source (e não uma licença livre, que fique claro) cuja parte open source foi devolvida à comunidade mesmo não sendo necessária essa devolução.

O Mac OS X da Apple atualmente é o sistema operacional que mais agrada aos meus requisitos e certamente eu usaria ele mesmo sendo um software proprietário (na verdade só não uso ele porque não tenho dinheiro para adquirir um equipamento da Apple). O OS X é muito flexível (bate um coração Unix em seu interior), é totalmente funcional (tudo o que preciso do mundo Linux e tudo o que o mundo proprietário me oferece pode ser usado no OS X), a usabilidade dele é simplesmente animal e o único contra dele é: ele é um software com uma parte proprietária.

Porque eu estou dizendo tudo isso em um blog sobre Python? Para que as pessoas entendam as minhas opiniões sobre outras linguagens de programação.

Eu não tenho essa ‘birra’ com Java “porque ela não tem uma implementação 100% livre de VM”. Eu tenho ‘birra’ de Java porque ela é menos flexível que Python (menos até que PHP) onde a flexibilidade aqui é primariamente uma referência à tipagem dinâmica de Python (existem outras características além dessa); Java no entanto empata em funcionalidades com Python, já que tudo o que se faz em uma se faz na outra; a usabilidade do Java é o seu maior problema e é onde Python simplesmente destroça com a ‘concorrência’; quanto às licenças a coisa complica um pouco mais. Java tem especificação aberta controlada por um consórcio de empresas, tem como máquinas virtuais (homologadas) apenas software proprietário, tem uma biblioteca padrão aberta mas com algumas coisas nebulosas como patentes da Sun, partes proprietárias, e outras coisinhas no ‘limbo’ legal desta plataforma. Python tem uma licença aberta reconhecida pela OSI uma lista de discussões aberta onde a evolução da linguagem é discutida e tem um BDFL (Benevolent Dictator for Life) que é o criador da linguagem (Guido van Rossum)

Sendo assim, minha preferência vai pra Python, porque dos critérios que eu uso para eleger um software bom Python ganha em 3 e empata em 1.

Note que em nenhum dos meus critérios eu incluo coisas idiotas como o “Deus Mercado” porque esse argumento já nos fez usar Cobol e Clipper no passado distante e no passado recente o “Deus Mercado” também nos dizia que deveriamos usar Visual Basic ou Delphi. O “Deus Mercado” nunca faz as escolhas pela razão, faz pelo dinheiro porque o dinheiro cria o hype e (conforme meu post anterior) o hype destrói projetos.

Faça seu projeto falhar em 5 lições

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.

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.

*sigh*

Atualmente estou trabalhando pra uma consultoria e estou desenvolvendo uma aplicação Java (com Struts) que irá fornecer uma interface Web para usuários do ERP da empresa cliente.

O sistema usa Java/Struts porque o cliente escolheu assim e a consultoria que elaborou o projeto endossou a tecnologia que seria usada. Como eu precisava garantir o “leitinho da criança” e eu queria ver como funcionava esse tal de Struts e também dar uma ‘reciclada’ Javiana no meu cérebro topei o projeto e estou aqui.

Para fazer um mini-controle de segurança nesta aplicação resolvi desenvolver um “mini sistema de persistência de objetos em banco de dados relacional” para atender a uma demanda do sistema.

Eu havia escrito um “mini sistema de persistência de objetos em banco de dados relacional” para um projeto Python que eu tinha trabalhado a uns meses atrás. Ficou bem simples (porque senão eu usaria o SQLObjects que seria melhor) mas funcionava para o que eu precisava fazer. Levei 8 horas pra pensar e desenvolver ele inteiro.

Neste exato momento estou na minha 20ª hora de trabalho em Java e não tenho algo funcional. Vocês podem dizer “Ah! mas você conhece bem Python e não conhece bem Java!” mas eu retrucaria com um “Eu conheço Java e desenvolvi bastante em Java”. E ainda tem outros fatores que devem ser considerados:

  • Eu já havia feito um sistema assim antes (em Python), portanto, não precisei elaborar nada dele porque já tinha a estrutura dele toda em mente.
  • Estou usando uma ferramenta chamada jDeveloper da Oracle que disponibiliza um mooonte de facilidades como: suporte a Refactoring integrado (com funcionalidades que dificilmente existirão para Python pelo carater dinâmico da linguagem), integração com jUnit, sistema de ajuda integrado, etc. Ou seja, uma ferramenta com muito mais facilitadores do que o Vim que usei para desenvolver a minha versão pythoniana.

Ainda não mexi muito com o Struts para poder ‘avacalhar’ com ele da forma com que gostaria. Mas as primeiras impressões que ficaram é que é mais um daqueles frameworks onde você tem que saber mais XML do que Java para poder usá-lo.

Acho que no universo Java eles tentam fazer bastante coisa com XML para livrar o desenvolvedor da burocrática linguagem de programação que Java é.

PS. Não usei Hibernate, JDO, EJB, J2EE, etc… para persistir meus objetinhos porque levaria mais tempo pra eu configurar esses caras do que para desenvolver a solução toda. Além disso o cliente tem restrições com a utilização de determinadas bibliotecas / frameworks / tecnologias que ele não domina. Paciência, fica pra próxima vez a chance de conhecer mais uma coisa pra eu poder avacalhar (sim, porque eu não gosto de avacalhar com coisas que eu não conheço).

Python, Windows e exigências do ofício

Atualmente tenho trabalhado no desenvolvimento de um software de Webmail que será acessado via Wap (Wireless Application Protocol) e para que eu possa testar o funcionamento deste sistema precisei passar uma temporada usando Windows.

Alguns devem saber que eu simplesmente detesto o Windows (e acreditem, não é porque é um software da Microsoft, não gosto porque simplesmente é um péssimo software) e para que o sofrimento não fosse muito grande, tratei logo de instalar alguns softwares do universo Opensource em minha máquina. Além desses instalei também o Cygwin que trouxe um ‘sopro’ de felicidade ao meu trabalho.

Mas voltando ao assunto Python (que é sobre o que se trata esse Blog) eu acabei por instalar o Python 2.2 para essa tarefa (o servidor que rodará a aplicação de Wapmail usa um RHEL que disponibiliza a versão 2.2 do Python e instalar uma mais nova seria ‘politicamente complicado’) e instalei também o Python 2.4 para ter uma versão mais bleeding edge do Python.

Como fiquei sabendo somente um tempo depois que na máquina que rodaria a aplicação tinha apenas o Python 2.2 acabei por desenvolver uma quantidade considerável de código em Python 2.4 e quando fui rodar no Python 2.2… caos! desordem! fim dos tempos!… tá, não foi tudo isso, mas a aplicação quebrou em vários lugares e aí eu, pela primeira vez, comecei a notar que nem todas as mudanças de comportamento das bibliotecas do Python estão corretamente anotadas na documentação oficial da linguagem.

Trabalhar com versões diferentes de uma mesma linguagem sempre traz transtornos para o desenvolvedor (não importa a linguagem… já tive problemas do mesmo tipo com Java mas a solução demorou mais) e por isso fica registrada a dica aqui: verifiquem qual versão do Python e das bibliotecas que você vai usar antes de começar a desenvolver.

Antes desse projeto estava trabalhando em um outro que envolvia fazer integração de Python com o Internet Explorer e com o Microsoft Word. Para essa tarefa a única alternativa existente são os módulos para Win32 do Mark Hammond.

Vou dizer uma coisa pra vocês: É raríssimo encontrar um conjunto de módulos para Python que sejam tão completos quanto esse. Ele tem suporte a tudo o que você possa precisar para integrar sua aplicação com a plataforma Microsoft. A única coisa que é relativamente ‘sofrível’ é a documentação que basicamente é uma meia dúzia de arquivos e um acesso ao Microsoft Developers Network (que é tosco).