Google, Microsoft e… Python

A notícia (original em inglês) já não é tão nova assim mas Guido van Rossum, criador da linguagem Python, foi contratado para trabalhar no Google. Como alguns já sabem o Google é um dos maiores, mais antigos e mais importantes usuários da linguagem Python atualmente. O Google usa Python em diversas partes de seus sistemas como nos crawlers (procure por “Python”) e no sistema de Helpdesk deles (olhe a URL dessa página e veja o “.py”).

Segundo a notícia a contratação de Guido van Rossum mostra a importância que Python tem dentro do Google.

A outra notícia (que saiu no IDGNow!) é boa mas é ruim. Boa porque sempre é bom que uma empresa grande “abrace” uma linguagem de programação e dê apoio ao seu desenvolvimento. Ruim porque essa tal empresa que está abraçando a idéia de Python é conhecida por suas práticas desleais na área de tecnologia. Agora é aguardar, ver como as coisas vão desenrolar e torcer para que as intenções da Microsoft, pelo menos com relação à Python, sejam as melhores possíveis.

O legal dessa notícia é que ela também saiu na ‘grande imprensa’ tecnológica e não em um site do circuito de Software Livre onde as notícias sobre Python costumam circular. Esse já é uma dos bons efeitos colaterais que se obtêm quando uma grande empresa abraça a nossa causa.

publicado
Categorizado como Geral

Zope é bom mas é ‘difícil’

A muitos anos atrás (tá, nem tantos assim) eu resolvi me aventurar com Zope. Eu era ‘garoto novo’ e bastante inexperiente com desenvolvimento OO. Me dei mal. Não sei se a coisa não rolou por causa dessa inexperiência ou porque Zope realmente era complicado. Mas o resultado foi: não deu.

Algum tempo depois fiquei mais experiente em OO e já me julgava capaz para fazer uma nova tentativa com o Zope. Modéstia à parte não sou um ‘toupeira’. Tenho uma experiência muito boa no desenvolvimento de Software e no trato com computadores e agora que já estava ‘afiado’ com desenvolvimento OO estava tudo indicando que dessa vez eu e o Zope teríamos um caso de amor.

Me adaptei super-rápido com o ZODB, super-mal com todo o resto. Não rolava desenvolver na Web e não gostei da idéia de guardar o código de minhas aplicações dentro do ZODB. Eu sei que ‘não gostei’ não é um argumento técnico muito forte mas mesmo assim abandonei o Zope porque achei que eu não era dígno de compreender a proposta dele.

Ganhei um treinamento ultra-fast-rápido com o Luciano Ramalho e continuei não gostando de algumas coisas.

Resolvi dar uma olhada no Plone e que era o melhor tipo de aplicação feita em cima do Zope que poderia existir. Assisti a uma apresentação sobre Archetypes e ArchgenXML proferida por caras que realmente souberam explicar o funcionamento deles.

Archetypes eu achei muito massa. ArchgenXML eu não gostei porque tenho ressalvas contra qualquer tipo de ferramenta que tente gerar código. A minha opinião pessoal é a de que a única ferramenta que consegue gerar código automaticamente se chama programador.

Aí chegou o Zope3 que simplesmente sumia com algumas das características que eu julgava indesejadas anteriormente. Parece que agora o ‘casamento’ sai.

Para tarefas triviais ainda é um canhão muito grande para matar pequenas moscas mas me parece que está se tornando uma boa ferramenta para desenvolver aplicações maiores.

Armei-me do que existe de melhor em termos de documentação sobre o Zope3 (até livros caros e importados) e estou atacando o dragão para desenvolver uma aplicação exemplo de controle de finanças pessoais (para meu uso). Tá saindo. Muito, mas muito mesmo, mais devagar do que se eu estivesse usando um framework mais ‘leve’ como um Turbogears ou o Django mas mesmo assim tá saindo.

Mas vou falar uma coisa: não é fácil. A facilidade de se aprender Zope é inversamente proporcional à facilidade de se aprender Python. Notei que sempre foi assim. Só estou conseguindo agora porque tenho muito mais experiência do que antes para tentar, mas se você está tentando aprender Zope agora não se ache um ‘burrão’ igual eu me achei no passado porque isso não é verdade. A verdade é que o Zope é um bicho muito difícil de domar mas depois de domado é o bicho mais poderoso que você pode ter em mãos.

publicado
Categorizado como Geral

Bug ou comportamento indesejado?

Estou trabalhando na construção do pacote do Python 2.4.2 para a plataforma Maemo e uma das nossas missões nesse projeto é fazer com que os pacotes com o Python ocupem pouco espaço em disco. Essa missão vem do fato que a plataforma Maemo é projetada para dispositivos móveis que não costumam ser construídos com discos muito grande.

Para reduzir essa ocupação de espaço resolvemos distribuir apenas os módulos otimizados (.pyo) da biblioteca Python porque esses arquivos são menores que os seus equivalentes em código fonte (.py) que serão distribuídos em um pacote separado específico para desenvolvedores. Outra mudança que fizemos foi distribuir esses pacotes dentro de um arquivo .zip.

No entanto, descobrimos posteriormente que o FS do N770 já é comprimido e colocar os módulos dentro desse .zip se tornou desnecessário. Enquanto eu ‘tirava’ os módulos de dentro do ZIP eu esbarrei numa inconsistência no comportamento do CPython que vou ilustrar na seção abaixo:

  1. Primeiramente eu crio dois módulos compilados. Um deles com otimização e o outro sem e adiciono os mesmos dentro de um ZIP:
$ ls
modulo_c.pyc  modulo_o.pyo
$ zip modulos.zip modulo_o.pyo modulo_c.pyc
  adding: modulo_o.pyo (deflated 38%)
  adding: modulo_c.pyc (deflated 38%)
$ ls
modulo_c.pyc  modulo_o.pyo  modulos.zip
  1. Depois aciono o interpretador em modo normal (não-otimizado):
$ python2.4
>>> import modulo_c
modulo_c
>>> import modulo_o
ImportError: No module named modulo_o

Como puderam observar, o interpretador Python não procura arquivos com a extensão .pyo quando está em modo não-otimizado.

  1. Na seqüência eu aciono o interpretador em modo otimizado:
$ python2.4 -O
>>> import modulo_c
ImportError: No module named modulo_c
>>> import modulo_o
modulo_o

E o comportamento inverso pode ser observado. O interpretador também não procura módulos .pyc quando está em modo otimizado.

  1. Removo os módulos .pyc e .pyo para ficar com eles apenas dentro do Zip e repito os passos anteriores dizendo que o ‘modulos.zip’ agora faz parte do PYTHONPATH e deve servir de local para procura de módulos Python:
$ rm *.pyc *.pyo
$ ls
modulos.zip
$ PYTHONPATH=modulos.zip python2.4
>>> import modulo_c
modulo_c
>>> import modulo_o
modulo_o
$ PYTHONPATH=modulos.zip python2.4 -O
>>> import modulo_c
modulo_c
>>> import modulo_o
modulo_o

Aqui está a inconsistência. Utilizando o hook zipimport do Python ele procura por módulos .pyc e .pyo no PYTHONPATH. A única distinção que ele faz entre os dois modos é a de que no modo normal o interpretador procura na ordem “py->pyc->pyo” e no modo otimizado ele procura na ordem “py->pyo->pyc”.

Acho que essa inconsistência tem que ser eliminada e, em minha humilde opinião o comportamento do hook zipimport é mais adequado do que o do primeiro porque poderemos encontrar casos onde bibliotecas bytecode sejam fornecidas como .pyo e .pyc misturados (ok, eu sei que só renomear o arquivo já que o bytecode é o mesmo, mas não acho essa solução muito ‘elegante’).

Estou preparando um patch para deixar o comportamento do hook de importação padrão do Python funcione de maneira equivalente ao hook zipimport e vou submetê-lo para o projeto. Mas como esse patch tem uma solução baseada na minha visão eu gostaria de saber antes a opinião dos leitores: Qual dos 2 comportamentos deve permanecer? E, isso deve ser mudado?

publicado
Categorizado como Geral

Python 3

Para quem tem acompanhado a lista de discussões Python Developers já deve ter percebido que as discussões sobre a versão 3 da linguagem Python vêm se intensificando a cada dia que passa.

Já foi dito a algum tempo atrás nessa mesma lista que a preocupação de manter compatibilidade retroativa com as versões atuais da linguagem Python serão praticamente nulas. Os desenvolvedores da linguagem se deram ao direito de quebrar essa compatibilidade para que finalmente eles possam corrigir erros de design que acompanham a linguagem desde as suas primeiras versões.

É importante que todos que usam Python intensivamente comecem a acompanhar essas discussões para já irem evitando certas ‘construções’ que não farão mais parte da linguagem no futuro. Existe uma quantidade considerável dessas ‘construções’, portanto, não vou ficar listando-as por aqui. Elas podem ser vistas em forma de propostas na PEP3000.

A sensação de acompanhar as discussões é: tensão. Eventualmente o Guido (BDFL) opta por algumas regras sintáticas e/ou construções na linguagem que me deixam consternados. Mesmo quando elas não passam apenas de propostas. Um caso recente foi quando ele sugeriu trocar os operadores lógicos “and”, “or” e “not” por “&&”, “||” e “!” como em linguagens com sintaxe baseadas na sintaxe da linguagem C.

Eu fiquei tenso por algumas horas até que várias pessoas votaram para que essa modificação não ocorresse. Eu fiquei preocupado porque eu gosto de ler uma expressão lógica como se estivesse lendo um parágrafo de um livro (if foo and bar:…) e não como se tivesse lendo uma tábua com hieroglífos (if foo && bar:…).

Outra sugestão que deram foi a de mudar o comportamento do retorno de expressões lógicas. Atualmente a linguagem Python usa um mecanismo de short-circuit para avaliar uma expressão lógica e o último elemento avaliado será retornado. Queriam que esse tipo de expressão retorne apenas “True” ou “False”. Acho que ambos comportamentos possuem vantagens e desvantagens e mudá-lo por mudar só faria com que mais código se quebrasse gerando erros realmente muito difíceis de encontrar. Ok, eu disse que já foi avisado que compatibilidade retroativa não é uma preocupação para o Py3, mas realmente é necessário quebrar compatibilidade com algo tão gratuito? Acho que não e parece que tem mais pessoas que pensam assim. A discussão saiu dessa linha de raciocínio e partiu para uma linha de proposta para criar um equivalente ao operador ternário da lingagem C (?:). Evidente que estão procurando uma sintaxe mais adequada do que a sintaxe usada pela linguagem C.

Eu gosto muito de Python e confio no julgamento do GvR para tomar decisões no desenho da linguagem, mas acompanhar as discussões na lista em tempos de mudanças tão grandes realmente não é indicado para programadores Python com coração fraco.

Em tempo: O pessoal do INdT e eu organizamos um pequeno “Planet” que ainda está hospedado em local temporário esperando pela liberação do domínio “maemo.org.br”. A versão provisória do Planet pode ser encontrada em “http://evolutum.gotdns.com/~osvaldo/planet/“.

publicado
Categorizado como Geral

Conhecimentos fundamentais

Ja faz algum tempo que tenho notado em diversas listas de discussões da área de informática que alguns profissionais de nossa área parecem estar entrando para o mercado de trabalho sem ao menos ter alguns conhecimentos mais fundamentais sobre computação.

Um “Conhecimento Fundamental” não é um “Conhecimento Essencial” mas é extremamente útil ter esse tipo de conhecimento quando se trabalha com qualquer coisa.

Na minha simplória definição um “Conhecimento Fundamental” é um tipo de conhecimento que não necessariamente é aplicado diretamente na resolução de um problema mas que certamente enriquece muito a ‘teia’ de informações disponíveis em nossa mente. Esse enriquecimento faz com que a gente consiga apresentar soluções muito mais criativas e eficientes para determinados problemas.

Para esclarecer um pouco melhor o que eu estou tentando dizer vou citar algumas situações reais que ocorreram com algumas pessoas próximas à mim.

Operações bit-a-bit

Quando eu fiz escola técnica no segundo grau eu tive um professor (Victor) que passou um semestre inteiro explicando aritmética binária, operações bit-a-bit e um básico de lógica booleana (que no semestre seguinte foi complementada de maneira adequada por outro professor).

Nessa época vários colegas de classe ‘matavam’ essa aula porque ela realmente era bastante teórica e pouco prática e esses alunos estavam mais interessados ou em jogar Truco no páteo do colégio ou em ver o último livro de Clipper (que era a ‘sensação’ da época da mesma forma que Java é a ‘sensação’ do momento).

Eu assisti essas aulas e aprendi sobre deslocamento de bits, soma, subtração, multiplicação binária, aprendi como um número negativo era representado binariamente (complemento de dois e afins), e por aí vai.

Quase uma década depois eu e mais algumas pessoas em Curitiba fizemos um teste prático em linguagem C para entrar no meu atual emprego no INdT. O desafio proposto pra mim era corrigir uma função de um compressor de arquivos que fazia deslocamentos de bits e umas operações bit-a-bit com máscaras.

Corrigi a função (estourei um pouco do tempo disponível) e passei no teste. Algum tempo depois um atual-companheiro de trabalho saiu da sala e havia me dito que ele se atrapalhou com o desafio dele (que também envolvia deslocamentos e manipulações de bits) porque ele não lembrava a sintaxe da linguagem C para fazer deslocamentos de bits (>).

Se eu estivesse na mesma situação que ele eu teria solucionado o problema usando uma ‘alternativa’ à sintaxe da linguagem C e faria sucessivas multiplicações e divisões por 2 que fazem com que os bits se desloquem para à esquerda e direita respectivamente.

Esse foi um caso real onde um “Conhecimento Fundamental” teria ajudado esse meu amigo. De qualquer forma ele se deu bem no restante do teste e hoje ele trabalha aqui do meu lado.

Recursividade

A algum tempo atrás precisei desenvolver um pequeno script pra um provedor de internet que calcularia o valor com pulsos gastos pelos assinantes desse provedor para que posteriormente fossem oferecidos produtos de banda-larga para clientes que fazem uso maior de internet.

No momento em que estava pensando na forma que eu resolveria esse problema (que eh desnecessariamente complicado) emergiu dos fundos de meus “Conhecimentos Fundamentais” as minhas aulas sobre recursividade. Usei uma prática muito simples de ‘dividir e conquistar’ as ligações que encaixavam em diversas categorias diferentes de tarifação chamando a mesma função de cálculo recursivamente.

Evidente que esse script não prevê todos os casos e situações diferentes com as quais uma operadora de telefonia precisa se preocupar mas serviu adequadamente para resolver o problema em questão.

Recentemente um amigo que presta serviços para um provedor de internet que pertence à uma operadora de Telecom me disse que a equipe de desenvolvimento dessa empresa estava ‘batendo cabeça’ a várias semanas tentando resolver o mesmo problema.

Eram desenvolvedores que não possuem “Conhecimentos Fundamentais” para exercerem suas funções. Passei esse script para que o pessoal usasse.

Conhecimentos Fundamentais não envelhecem

Os profissionais de informática hoje perdem muito tempo escolhendo uma faculdade ou outra, um curso ou outro porque uma delas usa Windows e a outra Linux. Uma usa Java e a outra .Net. Algumas ainda usam Pascal e outras começam a usar Python. Os alunos ‘brigam’ com seus professores para que os mesmos ensinem Java ou C# mas nunca brigam com eles pedindo para que explique sobre Autômatos Finitos ou máquinas de Turing.

Saber Java ou C# hoje é o mesmo que ter sabido Clipper ou Cobol à alguns anos atrás. É um tipo de conhecimento que ‘envelhece’ e perde o sentido. Não é um conhecimento desnecessário, mas a aquisição desse tipo de conhecimento deveria ter uma prioridade menor do que os “Conhecimentos Fundamentais”.

Fundamentar o conhecimento é algo imprescindível que torna mais fácil, inclusive, adquirir outros tipos de conhecimentos.

publicado
Categorizado como Geral

À Sombra de Titãs

Não, eu não morri. Sim, estou passando por uma crise criativa. E já vou avisando que esse post está completamente mela-cueca e “puxa-sacos” 🙂

Todo nerd é saudosista. Se isso não fosse verdade nós não nos interessariamos por coisas como MSX, TRS-80 e Apple II. Como nerds costumamos chamar de antigüidades enquanto os outros chamam apenas de lixo ou velharia.

Com meu ‘bit’ saudosista habilitado (só nerd pra escrever essas coisas) resolvi fazer um levantamento do meu envolvimento com as pessoas da Comunidade do Software Livre brasileira.

Eu tive uma sorte muito grande de sempre ter convivido ao lado de “Titãs” do Software Livre. Se fosse possível “aprender por osmose” eu certamente seria um gênio mas infelizmente não é. Para homenagear essas pessoas resolvi dar nome aos GNUs (ha ha ha que tentativa horrível de fazer um trocadilho).

O legal desses GNUs é que nem sempre eles aparecem ‘na mídia’ ou são tratados como ‘personalidades’ por outros membros da comunidade mas certamente eles fizeram algo pelo Software Livre.

Meu envolvimento com Software Livre começou efetivamente em 2000 quando comecei a trabalhar na Conectiva. Antes disso os programinhas Clipper que eu fazia eram liberados mas não sabia que isso era SL.

Hoje eu tenho a impressão que fui trabalhar lá por causa de uma ‘falha’ no processo de contratação. Só pode ter sido isso essa a razão. Afinal, nessa época eu não me envolvia com comunidade, me batia por dias tentando estabelecer uma conexão PPP (e nem era Winmodem :P) e nunca tinha conseguido concluir com sucesso uma compilação de kernel :). Nunca tinha feito uma linha de código em C para ambientes Unix (só para DOS) e mesmo assim fui parar no departamento de Pesquisa & Desenvolvimento da Conectiva. Meu inglês hoje é muito ruim, imagine naquela época 🙂

Lá na Conectiva, que hoje se chama Mandriva, trabalhava a elite do Software Livre brasileiro. Alguns desses profissionais ainda estão por lá e outros estão ‘por aí’. Para citar alguns: Arnaldo Melo (acme), Cavassin, Rodarvus (vulgo Rodrigo), Gustavo Niemeyer (Python, Smart, …), Sérgio Bruder (PontoBR), Cláudio Matsuoka (um moonte de coisas), Hélio (KDElio), Alfredo Kojima (WindowMaker, apt-rpm, …), Aurélio (verde, que à época era o verde666), Paulo César Andrade (driver Vesa pro XFree86), etc etc etc etc etc… E eu lá, no meio desse monte de gente 🙂

Não preciso dizer que ter trabalhado na Conectiva é equivalente a jogar na Seleção Brasileira para um jogador de futebol.

Algum tempo depois fui trabalhar Objective Solutions onde tive o privilégio de conhecer caras muito bons, entre eles: Klaus Wuestfeld (Prevayler). Na Objective eu aprendi a programar usando Orientação à Objetos.

Trabalhar com Python também faz com que a gente tenha contato com pessoas fora do comum no quesito inteligência. Não é qualquer comunidade que dispõe de pessoas do naipe de Luciano Ramalho, Érico Andrei, Jean Ferri, Rodrigo Senra, Pedro Werneck, Xiru, Sidnei da Silva, Gustavo Barbieri, José Nalon, etc etc etc.

As pessoas que fazem muito blablabla (chamados de “Boi” pelo Júlio Cezar Neves) deveriam se inspirar no trabalho dessas pessoas citadas aí em cima e parar de ficar discutindo coisas inúteis sobre “Melhor distribuição Linux”, “Gnome vs. KDE” ou outra coisa do tipo.

publicado
Categorizado como Geral

A LER e a DORT

Por falta total de idéias para postar por aqui e por ter participado hoje de uma ginástica laboral no trabalho resolvi tratar de saúde.

Não existiria alguém mais inadequado para falar de saúde do que eu, um inveterado anti-atividades-físicas, mas nos casos específicos da LER e das DORT eu até atrevo a emitir uns comentários. Me atrevo porque já sofri consideravelmente com dores nos pulsos causadas por uma tendinite tratada à base de repouso prolongado e anti-inflamatórios.

Para nós programadores ‘repouso prolongado’ geralmente causa alguns problemas financeiros (principalmente quando se trabalha como ‘terceirizado’) e para evitar esse tipo de problema para meus colegas de trabalho vou tentar dar alguns conselhos de vários tipos para poupá-los de tais problemas.

Antes de começar vamos definir de forma simplista o que significa LER (Lesão por Esforço Repetitivo) e DORT (Distúrbio Osteomuscular Relacionado ao Trabalho).

A LER é uma lesão (como o nome diz) que é causada pela movimentação repetitiva de partes do nosso corpo. Exatamente o tipo de movimento que meus dedos estão fazendo enquanto digito esse texto ou movimentando o mouse.

A LER é um tipo de DORT. DORT é qualquer problema causado à nossas estruturas ósseo/muscular por atividades relacionadas ao trabalho. A LER é a mais famosa delas.

Após essas definições supersimplificadas que certamente causarão arrepios aos mais experientes professores de educação física e fisioterapeutas que lerem esse post vamos à algumas medidas que visam melhorar as nossas chances de não desenvolver um desses problemas.

Postura

Quando eu me sento para trabalhar pareço um lord-inglês. Postura ereta, cabeça posicionada corretamente, pés plantados completamente no chão e os braços e pernas formando ângulos retos. Essa posição dura cerca de 5 minutos. Esse é o tempo necessário para que eu me perceba praticamente deitado no assento das cadeiras e as mão digitando na altura da cabeça.

Esse problema tem sido o mais difícil de resolver e minhas costas já estão avisando que é bom eu providenciar rapidamente uma solução. Se eu praticasse alguma atividade física que fortalecesse a musculatura das costas esse problema diminuiria consideravelmente mas, definitivamente, sou preguiçoso demais para fazer isso 🙂

Estou pensando em me amarrar com um cinto bem apertado na linha da cintura à cadeira (da mesma forma que a gente usa cintos de segurança de 2 pontas). Assim eu não ‘escorregaria’ para baixo da mesa 🙂 Vou consultar algum especialista na área, experimentar isso e depois falo qual foi o resultado 🙂

Eu não achei uma boa ilustração para colocar aqui com a postura ideal para se usar um computador mas basta lembrar de algumas regrinhas:

  • Braços e pernas formam ângulos de 90 graus.
  • Braços apoiados completamente sobre a mesa.
  • Pés plantados completamente no chão.
  • Tronco ereto e olhos olhando para o ‘horizonte’.
  • Parte de cima da tela do monitor deve estar exatamente na altura dos olhos.

Equipamentos

Algumas dicas importantes para o uso do ‘equipamento’:

  • Não use aqueles apoios de braço. Eles fazem com que seu braço não fiquem totalmente escorados na mesa.
  • Use luvas imobilizadoras somente sob orientação de médico. Essas luvas podem até piorar a situação. Cuide também para, caso usá-las, não apertar muito para não prejudicar a circulação.
  • Se você tiver dinheiro para ‘gastar’ compre bons teclados e mouses. Gaste mais dinheiro nisso do que naquela super nVidia 9000GXF+++ que você estava pensando em comprar. Mouses e Teclados são um caso à parte por isso tratarei separadamente.
  • Eu prefiro monitores LCD aos CRT. Não só pela beleza e estética mas porque eles não oscilam e me dão menos dor-de-cabeça. Não sei se essa sensação tem algum fundamento científico mas minha experiência pessoal prefere o de LCD.

Teclados

Para nós programadores essa é a ferramenta mais usada. Então porque gastamos fortunas com placas de vídeo, memória e processador e sempre economizamos nesse dispositivo? Eu não entendo. Mas vou colocar aqui algumas coisas que eu, em minha experiência pessoal sem base científica/estatística alguma, percebi:

  • Teclados ABNT são melhores que teclado US para nós programarmos. Digitamos menos para obter um “ç”, ‘”‘ ou uma “‘” tão comuns para delimitar strings em um programa. Digitamos menos porque nos teclados ABNT essas teclas são separadas das teclas de acentuação tornando desnecessário ‘”‘+espaço para obter uma ‘”‘.
  • Prefira teclados cujas teclas tenham o ‘curso’ menor. Teclados de notebook são assim e alguns teclados para desktops à venda também possuem esse tipo de tecla.
  • Eu troquei o meu Caps Lock de lugar com o Control Esquerdo, assim, evito 2 problemas: ficar apertando Caps acidentalmente sempre que uso a letra “A” e fazer malabarismos para digitar as combinações Ctrl+A, Ctrl+S, …
  • Me disseram que teclados DVORAK economizam esse movimentos dos dedos, mas não sei se isso é verdade.

Mouse

Evite usar o Mouse. Crie muitas teclas de atalho nos programas que você usa. O movimento teclado-mouse-teclado prejudica o braço.

O Resto

Algumas outras dicas importantes:

  • Participe das ginásticas laborais no seu trabalho caso elas existam. Se não existirem tente convencer a ‘chefia’ para que elas aconteçam (não tente fazer você mesmo essa ginástica pois fazer essas atividades de maneira errada pode atrapalhar mais que ajudar).
  • Instale o Workrave em sua máquina e desative a opção de ‘postpone’ :). Recomendo seguir as atividades propostas pelo programa. Tem algumas muito legais. Dica: desligue esse programa antes de entrar no Counter-Strike 🙂
  • Eu não gosto, mas se você gosta: pratique algum esporte/atividade física.
  • Evite programar em linguagens que exijam muita digitação: ‘public static int main(int argc, String argv[]) { System.out.println(“foo”); }’. Prefira ‘print “foo”‘ 🙂

Seguindo essas dicas você garante mais alguns ‘anos de vida’ para seu pulso.

publicado
Categorizado como Geral

AppleScript e Python

O meu amigo Aurélio (verde) publicou um comparativo entre as linguagens AppleScript e Python para que programadores AppleScript possam começar a programar em Python e para que programadores Python possam começar a programar para AppleScript.

O comparativo esté em: http://aurelio.net/doc/as4pp.html

A muuuito tempo atrás eu programei um pouquinho (bem pouquinho mesmo) para AppleScript para automatizar algumas funcionalidades do QuarkXPress (software de editoração eletrônica) em um jornal que trabalhei e me lembro que realmente era muito fácil desenvolver nessa linguagem.

Na minha opinião ela peca por excesso de ‘verborragia’ e o principal problema dela é o fato de funcionar apenas na plataforma Apple.

Para os que pretendem desenvolver aplicações maiores para essa plataforma seria legal dar uma olhada na linguagem Objective-C e nos bindings Python para Objective-C.

publicado
Categorizado como Geral

Mini-curso Python

Sexta-feira passada ministrei um mini-curso de Python no meu trabalho.

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.

publicado
Categorizado como Geral

Tempo e disciplina

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.

publicado
Categorizado como Geral