Estou escrevendo esse parágrafo sentado em um dos cantos de um auditório. O palestrante, barbado, cabelos compridos e muito, muito engraçado, fala sobre empreendedorismo e conta a história das várias encarnações de sua empresa. Agora explica como ele, que faz serviços para uma empresa no exterior, tem sempre que ensinar os gerentes de conta que o atendem, que são trocados com mais frequência do que as plantas ornamentais da agência, como são feitas as operações de câmbio necessárias para que ele possa pagar suas contas.
Estou em um canto do auditório porque só há quatro tomadas livres. Quatro tomadas livres para, aproximadamente, 50 notebooks garante que sejam usados os expedientes mais perigosos para que se ligue os micros na tomada. Meu micro, já meio idoso e pedindo desesperadamente para ser devolvido à aposentadoria da qual um assaltante o tirou (sim, meu micro mais novo foi roubado em um assalto) tem uma bateria capaz de mantê-lo funcionando por, com sorte, cinco minutos me obriga a ver as palestras todas de lado.
O evento é o 3o. encontro nacional da comunidade Python.
Python é uma linguagem de programação extremamente elegante e expressiva e, se você não sabe nada sobre ela, continue assim. Eu a considero uma vantagem competitiva e se você, meu leitor, não souber do que se trata, melhor para mim.
Python é a linguagem em que várias ferramentas muito interessantes foram construídas. Zope e Plone são duas das minhas favoritas, principalmente por conta do meu trabalho com web, mas há montes de outras. Python é usado desde no monitoramento de linhas costeiras até na reconstrução volumétrica de imagens médicas. Eu aprendi tudo isso nos últimos três dias.
Na primeira noite do evento, a TV local se interessou e três de nós (Luciano, Érico e Marco) foram entrevistados por uma hora e meia em um talk-show. Eu não vi o vídeo e terei que esperar pela versão YouTube dele, mas os que estavam assistindo enquanto saíamos para conhecer uma cachaçaria local dizem que foi muito interessante.
Uma das coisas interessantes nesse evento é a ausência de uma grande empresa dominando-o. Não há muitos eventos assim hoje em dia.
E isso é muito importante.
Propaganda
Ao longo da minha carreira em TI, eu estive em muitos eventos, a maioria deles patrocinado por uma ou outra grande empresa. As palestras são escolhidas pela organização do evento e refletem seus pontos de vista e seus interesses.
Se você pagou para ir a um evento da Microsoft, por exemplo, parabéns. Você pagou para assistir um longo infomercial – umas 20 horas em que você ficou sentado recebendo as informações que queriam que você recebesse. É tão informativo quanto sintonizar a TV no Discovery Channel às seis da manhã.
Se você mandou seus funcionários para um evento da Microsoft, parabéns de novo. Você pagou para que eles fossem assistir um infomercial enquanto não trabalham. Se você espera que eles saiam do evento com uma visão realista do que viram, entre em contato. Estou vendendo uma ponte lindíssima por um preço muito abaixo do mercado. Uma verdadeira pechincha.
Uma vantagem de eventos como esse, organizados por associações de usuários (esse é organizado pela Associação Python Brasil da qual Luciano é presidente, Marcos coordena ações junto à instituições educacionais e da qual Érico deixou a diretoria de marketing) e conta com o apoio de várias empresas e outras instituições que usam, dependem ou acham Python interessante.
Para alguns isso pode ser um problema – você não vai ouvir falar de Java aqui, nem de PHP nem de outras tecnologias exceto piadas (quem não gosta de tirar um sarro do pessoal que prefere usar Java?) em comparativos mostrando como as tecnologias baseadas em Python, como Zope/Plone, Grok e Django são superiores aos suas contrapartes e, em alguns raros casos, o que as contrapartes fazem direito e onde precisamos melhorar coisas.
Colaboração
A outra coisa interessante é o modelo do Python e de várias outras das ferramentas mostradas aqui. Python é software-livre. Assim como Zope, Plone, Grok, Django, TurboGears, Storm, Pyjamas, WxPython, Pygnome, NumPy e Matplotlib, apenas para ficar naqueles que eu vi nas últimas horas.
Existem versões de Python para telefones Symbian S60, para Windows, para Solaris, para AIX, para Macintosh e para Linux. A versão Windows do Plone é, inclusive, muito popular. Olhando em volta vemos muitos Macs, muitos notebooks com Linux e muitos notebooks com Windows. Vejo também um UMPC Samsung e um Nokia N800, ambos rodando Linux.
Ao contrário do modelo de software proprietário (ou “software-preso”), segundo o qual somos todos inimigos ou, no máximo, comensais do fornecedor maior, o modelo livre incentiva a colaboração e a troca de informações.
E isso funciona muito bem.
Funciona bem porque muitos dos que estão aqui estão envolvidos diretamente no desenvolvimento das ferramentas que usamos. O resto está envolvido ativamente no uso dessas ferramentas e a interação entre esses dois campos rende frutos.
Quero ver alguém resolver algum problema do Exchange (e que ninguém diga que ele é perfeito) durante um desses “infomerciais” (que, volta e meia, você até tem que pagar pra ver).
Coisas que eu vi
Não tenho muito espaço para contar tudo o que eu vi aqui (estou escrevendo esse parágrafo no terceiro e último dia do evento), mas posso contar algumas das coisas que eu aprendi.
Eu vi mais coisas que podem ser feitas com Grok. Comparado a ele, coisas como Rails (Django e TurboGears também) parecem ecos de um passado longínquo. Bancos relacionais (o mecanismo preferido para persistir dados desde os anos 70) e programação orientada a objetos sempre se estranharam. Grok (e Zope3) mostram como se coloca uma pá de cal nessa história.
Vi muitas das coisas extraordinárias que apareceram na versão 3 do Plone. Simplesmente não existe nenhum gerenciador de conteúdo que chegue nem mesmo perto dele e, se você está usando qualquer outra coisa de livre e espontânea vontade, merece um tapão na nuca por isso.
Pensando bem, entre em contato comigo. Seus problemas com gerenciamento de conteúdo têm cura.
Outra coisa interessante é que a platéia (e o corpo de palestrantes) não é composta de computólogos, mas de um público muito mais amplo. Há engenheiros, biólogos, oceanógrafos, linguístas, designers, jornalistas, matemáticos e educadores. O elo comum é o interesse e a vontade de usar computadores para resolver seus (cabeludos) problemas. Python entra na brincadeira por ser elegante, concisa (algum Javista quer opinar?), fácil de aprender, fácil de obter resultados e, não menos importante, fácil de entender seis meses depois de você ter escrito o código.
Falando em Plone (ok, ok… eu gosto do Plone), tomei contato com vários projetos interessantes que o complementam, acrescentando conteúdo multimídia, por exemplo, e o tornam uma solução ainda mais conveninente de gerenciamento de conteúdos tanto para sites como para intranets.
É mais ou menos assim: se você mora no Brasil, já usou Plone. Eu usei outro dia para marcar um horário para renovar meu passaporte. O site do IDGNow roda em Plone. O site da OAB roda com Plone.
Superando os medíocres
Eu gosto muito de um artigo de Paul Graham chamado “Beating the Averages” (a propósito, editoras, anotem: eu adoraria traduzir o livro
É assim que eu vejo tecnologias como Python, Rails (verdade – eu acho mesmo, mas não tanto quanto Grok), Django, Zope, Plone e Grok. São tecnologias tão mais sofisticadas que compará-las a coisas como PHP, .NET ou Java é como comparar um motor de disco-voador com um motor de fusca. No caso do Java, a maior concessão que eu faço é a comparação do motor de disco-voador com um motor diesel de locomotiva
Para o Paul Graham e a ViaWeb, o Lisp funcionou permitindo que eles colocassem no ar recursos antes dos concorrentes gastando menos dinheiro enquanto isso. A conta é simples: se você precisa de 40 homens x hora para colocar algo no ar e seu concorrente precisa de 400, seu competidor queima seu capital dez vezes mais depressa do que você para ter os mesmos resultados. Se a tecnologia que você usa permite que você iguale as funcionalidades do seu competidor em menos de um dia, você vai parecer clarividente. Por outro lado, se você e seu concorrente usarem a mesma tecnologia e tiverem programadores igualmente competentes, essa vantagem vai evaporar.
Minha única preocupação é que meus concorrentes leiam meus textos e aprendam com eles. Mas tudo bem. Eu nunca escrevo tudo. 😉[Webinsider]
.
Ricardo Bánffy
Ricardo Bánffy (ricardo@dieblinkenlights.com) é engenheiro, desenvolvedor, palestrante e consultor.
10 respostas
Não sei não Alex.
Eu sou da velha guarda – comecei junto com o Ramalho (o Ramalho-Do-Bem, não o do Clipper) programando software educacional no Apple II. Eu sempre dou uma última olhada antes de mandar o código pra instância de desenvolvimento e costumo pegar (às vezes com ajuda de um ou outro unit-test) as piores coisas antes de virar a chave do Zope. Sei lá. De repente eu sou mais paciente (leia-se tolerante à lentidão) do que a maioria. Eu não ligo pro Eclipse+PyDEV levar mais de um minuto pra carregar. Nem pro NetBeans, nos dias deprês em que o trabalho é com Java. Mesmo no notebook anêmico que eu uso hoje em dia, o Zope restarta rapidinho, mesmo com um ZODB bem gordo.
O problema dos upgrades é chato sim. Mas tem cura: Nós, consultores. Quem entende o encanamento encontra rapidinho o que quebrou e descobre como trocar.
Outro lado do mesmo problema é que o Plone é software-livre. Se o problema do upgrade incomodar o suficiente, cedo ou tarde alguém aparece com uma boa solução. Se não existe uma solução é porque o problema não é tão terrível assim. Ou que tem muito mais gente fazendo sites novos do que upgradeando sites antigos.
O que me leva ao terceiro ponto: Plone é software sério. É mission-critical pra um monte de gente. Nâo se atualiza software assim a menos que você precise dos novos recursos. Ninguém aplica patches no Solaris, no HP-UX ou no zOS cegamente. Na verdade, ninguém devia sair fazendo isso nem em Linuxes (onde os patches podem ser automágicos).
Outro lado é que sistemas baseados em RDBMSs como o Drupal não guardam objetos de verdade e sim cópias desidratadas deles no BD. Como o modelo de dados é mais engessado, isso acaba se tornando uma vantagem na hora do upgrade – como o schema não muda, você pode trocar outros elementos sem muito impacto. Por outro lado, você amarga com ele quando fazer uma mudança pequena resolveria um problema estrutural sério.
Quanto a Zope 3, faço parte do coro que brinca que ele não precisava muito ser chamado de Zope. Ele é um animal completamente diferente e, em muitas coisas, completamente oposto ao Zope 2. E ele é simplesmente duca (ainda mais com Grok junto). É um jeito mais sofisticado de programar web.
Oi Ricardo,
É…eu tb abandonei o windows já faz alguns anos…Não troco um bom APT por nada deste mundo…
Agora, voltando ao assunto:
O Plone sacaneia demais no que se refere a incompatibilidade entre suas versões..Compara com o Drupal por exemplo…Eu não sou o PZP MAN, mas conheco e lido o suficiente por dia com eles pra saber do que falo…O negócio acaba por ficar monolítico, fez naquela versão vai morrer com ela até o fim…Tem até um post na lista do Zope sobre isso, se não me engano é até do Ramalho…Acho duca o Zope3, Plone 3 e tal, mas o que vou fazer com todo o legado? Fazer de novo?
Quando eu disse mudar uma linha e restartar é claro que me referi ao processo de desenvolvimento…Em producão só se for no servidor do Juquery mesmo…Eu acho um SACO isso, salva o arquivo, desliga zope, liga zope, browser, desliga zope, liga zope, bla bla bla…Programadores ERRAM o tempo todo! Sintaxe, vírgulas, etc. Não conheco nenhum que não cometa esses tipos de erros, por mais experiente que seja o sujeito… Putz, quanto tempo do meu dia eu fico esperando o zope renascer…
Entendeu meu ponto de vista? Eu entendi o seu e acho válido também…
Abracos!
Alex,
Muitos zopistas e plonistas usam MacBooks. Muitos deles até usam Windows neles (sacrilégio!). Eu uso Linux no meu notebook (saí do Windows anos atrás pra nunca mais olhar pra trás). Meditei bastante sobre usar Mac, mas o OSX é BSD demais pro meu gosto. Isso e não tem APT.
Como todo framework, o Plone tem suas complexidades e coisas mudam de uma versão pra outra. Algumas coisas que escrevemos quebram entre uma versão e outra, mas isso é normal. Eu alegremente trocaria a verboragia e letargia do Java/JSP/J2EE, a verborragia e a Microsofticidade do .NET e o jeito pedra-lascada de ser do PHP pelo excesso de inovação da dobradinha Zope/Plone.
Também não tenho pudores de restartar meu servidor de desenvolvimento quando mudo alguma coisa. Ele roda no meu notebook e ninguém daria pela falta dele nos 10 segundos que leva pra reiniciar.
Mas ninguém minimamente responsável faz testes de mudar uma linha em um servidor de produção, não é mesmo?
Eu, pessoalmente, acho que Python não é a melhor linguagem para se aprender a programar. Para isso, eu prefiriria algo mais simplório e poder apresentar coisas como memória, saltos e outras operações primitivas e ir apresentando coisas mais complexas à medida em que o aluno se mostrasse capaz de construí-las por si mesmo a partir dos fundamentos.
Acho tão lindo os zopistas e plonistas de plantão, tão entusiastas do open source todos lá com seus MacBooks de última geração, esquecendo que o Jobs é tão proprietário quanto o Gates…
Acho tão lindo quando você precisa migrar seu Plone de uma versão pra outra…
Acho tão lindo programar utilizando formulários no Zope…
Acho tão lindo quando você faz uma aplicação usando archetypes e a cada linha que você muda ter que reiniciar o Zope…
Enfim, tecnologias são tecnologias, a gente usa o que acha melhor..Eu mesmo uso Zope/Plone em uma boa parte do meu dia e não acho muito ruim não. Porém, ao vivo, as coisas não são tão lindas quanto o autor pinta.
Em tempo: python é uma linguagem realmente excepcional para aprender a programar.
Dirceu: Putz… Vou ligar já pro Marco pra pedir desculpas e pedir pra alterarem o texto no site.
Marco: Você tem permissão para errar meu nome quando achar mais conveniente (mas apenas em um artigo). 😉
Antes de mais nada: Bánffy, parabéns pelo artigo, ficou realmente muito legal.
Só uma correção: quando você diz Marcos, você está falando do organizador do evento? Se sim, o nome dele é Marco (André Lopes Mendes), sem o s no final.
Fabio,
Confirmo o que o Bánffy disse: trabalho na PyTown.com e grande parte de nossos clientes ficam em instâncias compartilhadas (vários plone sites em uma única instância do Zope), enquanto outros ficam em máquinas virtuais ou servidores dedicados (a minoria).
Zope 2 + Plone não são *tão* consumidores de recursos assim: temos clientes com Django que usam *muito* mais recursos (principalmente memória), por incrível que pareça.
Alexandre,
Zope 2 / Plone são voltados para gestão de conteúdo; usá-los fora desse escopo realmente não vale muito a pena. Grok / Zope 3 é *outra história*: servem bem para aplicativos triviais (websites simples) até pra aplicações extremamente complexas.
Dê uma olhada em Grok, Django, Pylons… e fuja o mais rápido que puder do PHP. A propósito:
s/bom e velho/velho/ 🙂
Muito bom o seu texto, parabens cara.
Também trabalho com PZP e concordo com o Fabio FZero lá! Existem projetos que não da pra usar PZP (infelizmente). Mesmo depois de ter descobrido esse mundo hoje ainda uso o bom e velho PHP para coisas mais triviais!
Mas quanto ao PyconBrasil, gostaria de ter ido…. pena que os melhores eventos são sempre no sul. Devemos divulgar as ferremantas aqui no nordeste também!!! Quem sabe o próximo evento ser em recife, ou ate quem sabe aqui em Maceió mesmo 😛
É, Fábio. Você usa o ZServer somente para as páginas dinâmicas e o que for estático você deixa na mão do Apache.
Fora os squid/cachefu que eu ainda não me aventurei a configurar, e tudo o mais que o sapiente Ricardo falou acima, mas que deixarão seu Plone extremamente veloz e robusto.
Mais ou menos, Fábio.
Muitos sites rodam Zope/Plone em máquinas virtuais – isso só depende da infra-estrutura. Eu posso garantir que um servidor mediano segura uma boa quantidade de sites movimentados sem muito mais do que um OpenVZ por baixo. Se o provedor de hospedagem for marginalmente competente, ele pode aumentar ainda mais a escalabilidade em várias ordens de magnitude usando caches e alocando espertamente os sites dentro de instâncias compartilhadas (coisa que é, mais ou menos, uma extensão lógica do popular modelo de shared hosting). Sendo algo ainda mais pesado, existem formas simples de separar completamente o gerenciamento do conteúdo da entrega propriamente dita. Com isso, o desempenho fica idêntico a o que se espera de um site estático e pode servir milhões e milhões de páginas por dia.
Hoje há, no Brasil, empresas que oferecem hospedagem Zope/Plone por R$29 mensais. Quem foi à PyConBrasil ganhou de presente um pacote de hospedagem na PyTown.
Muita gente também não entende o modelo de desenvolvimento dele. Quem está acostumado a montar sites na mão sofre muito quando precisa desenvolver dentro de um framework riquíssimo como ele. Qualquer um monta sites com Dreamweaver. Qualquer um consulta dados em um MySQL usando PHP ou SQL Server com ASP. Não há grandes barreiras de entrada nessas tecnologias. A pergunta é se o cliente quer que _qualquer um_ faça o site dele. Veja bem – barreiras de entrada garantem alguma qualidade de mão de obra.
Plone é, vale não esquecer, um software de gerenciamento de conteúdo. Se você precisa de um gerenciador de conteúdo, ele é fantástico e, provavelmente, o mais avançado do mercado (incluindo aí soluções proprietárias caríssimas). Se você quer outra coisa muito diferente, você pode até usá-lo, mas ele não vai ajudar muito.
Eu concordo que o Plone é completíssimo, mas nada é perfeito: por precisar do Zope, ele é uma plataforma muito custosa em termos de recursos. è impossível rodar sistemas em Plone/Zope em shared hosting – e muitos projetos famosos começaram nesse esquema (o onipresente Digg, por exemplo).
O Zope pode ser lindo e ter 1278632984 vantagens e facilidades de desenvolvimento, mas é mais ou menos como ser obrigado a instalar uma mega-fábrica de motores para carros de corrida quando você precisa de uma lambreta. É uma camada de abstração complexa demais para grande parte dos projetos web.
Eu adoraria usar mais Python para web (já uso bastante para projetos em desktop), mas no momento não tenho como instalar o Django na minha conta do Dreamhost. Isso me fez estudar Ruby (que acho uma linguagem legal, mas malandrinha e metida a esperta demais pro meu gosto) e Rails. Nada contra Rails, mas bem que ele podia ser em Python também. 😉