Blog

  • Aposentadoria da Python Brasil

    Aposentadoria da Python Brasil

    Ontem eu me aposentei da moderação da lista de discussões Python Brasil. Quem vai assumir o meu cargo vai ser o meu ajudante Pedro Werneck. E ele, por sua vez, será ajudado pelo recém “contratado” Andrews Medina.

    O ritual de passagem da ferramenta de moderação usada na Python Brasil já foi até concluído.

    Quando comecei na lista éramos 134 assinantes e estamos com 2099 agora. Antes éramos só um grupo de amigos e entusiastas. Hoje continuamos amigos e entusiastas mas também somos associados de uma organização formal que vai ter muito mais força para levar adiante os nossos projetos.

    Essa aposentadoria é um dos passos rumo à minha redução de atividades na comunidade Python Brasil e de Software Livre em geral. Notem que irei reduzir consideravelmente as minhas atividades mas sempre serei um entusiasta de Python e do Software Livre em geral.

    Essa decisão também tem uma relação com a chegada dos meus trinta anos de idade e tomou a sua forma final durante as minhas últimas férias.

    Quero diminuir o número de coisas que faço para poder fazer melhor algumas outras coisas que andavam meio abandonadas: cuidar da família, desenvolver um projeto de software que ocupa meus pensamentos há muitos anos e fazer o meu trabalho melhorar aqui na empresa.

  • Desempregado ou despreparado?

    Desempregado ou despreparado?

    Nessa semana a empresa onde trabalho me pediu uma ajuda para conseguir contratar um programador Python com uma certa urgência. Como eu sou o moderador da lista Python Brasil optei por enviar um e-mail ligeiramente diferente para a lista de discussão avisando da oportunidade. O e-mail terminava assim:

    Esse artigo é antigo e já não reflete totalmente o meu modo de pensar. Estou mantendo ele aqui apenas por razões históricas.

    Requisitos:
     - Desenvolver pra Linux (necessário)
     - Desenvolver em Python (necessário)
     - Saber inglês (necessário)
     - Se divertir programando (necessário)
     - Desenvolver em C/C++ (plus)
     - Desenvolver Gtk+/GNOME (combo plus)
     - Ter estudado ciências ou engenharia da computação (mega-combo plus)
     - Conhecer bem plataforma ARM (qual é o teu telefone?)

    A partir daí eu fui recebendo e-mails e mais e-mails com curriculums de candidatos à vaga e pude ver que os erros básicos que já vi em outras oportunidades continuam sendo cometidos.

    Pessoal, as coisas que eu vou dizer aqui são sérias e a forma com que vou dizê-las pode ser um tanto contundente. Mas entendam que é para o bem de quem pretende conseguir um trabalho interessante. Algumas pessoas irão se reconhecer no que eu vou dizer abaixo mas para elas eu quero dizer que não é nada pessoal são apenas conselhos de alguém que trabalhou em bons lugares.

    Não lamente, corra atrás

    Uma quantidade considerável dos e-mails que recebi dessa vez (e de outras vezes) são de lamentação. Algo do tipo “Pôxa, que pena que eu não programo em Python muito bem :(“.

    Vamos ser inteligentes. A oferta diz: “Desenvolver em Python (necessário)”. Que parte de “necessário” não foi possível entender do texto? A gente quer um candidato à vaga não uma pessoa precisando de afago.

    No lugar de se lamentar por “não saber Python” você deveria é correr atrás de aprender. Nunca gastei um único tostão pra aprender Python, logo, não ter grana não serve como desculpa. Quando aprendi Python trabalhava em dois empregos e ainda tentava fazer uma faculdade. Isso também elimina a falta de tempo como desculpa.

    Mesmo que você tenha uma boa desculpa pra não ter aprendido Python você vai ter que pensar sobre o que você realmente quer da sua vida: a vaga ou alimentar sua desculpa.

    Se você não tem um bom projeto em Python para trabalhar fique sabendo que tem milhares de projetos de SL esperando pela sua ajuda. Escolha um que te faça feliz e toca o barco.

    O salário será aquele que você irá merecer

    Um outro tanto de e-mails que recebi tinham a pergunta: “Qual é o salário?” e na oferta estava escrito: “Salário acima da média local”.

    Não se pergunta o salário sem você ter sido sequer entrevistado. O salário é a última coisa que se fala com o candidato. Se tá dizendo que é acima da média local significa que é um salário mais alto do que o que você conseguiria por aqui, entende ou quer que eu desenhe?

    Sei que isso é utópico e que as “coisas práticas” são importantes, mas você já pensou que a empresa está te contratando para ajudá-la e não para ter mais um valor saindo mensalmente do seu caixa? Já pensou que você será remunerado na mesma proporção da sua contribuição à empresa?

    Se você contribui pouco para a empresa X você vai ganhar pouco. Se a empresa Y diz que paga acima da média local significa que você vai ganhar mais que a empresa X mesmo fazendo pouco.

    Quando eu tenho vontade de trabalhar numa empresa eu penso na quantidade de coisas legais que eu posso fazer nessa empresa e não em quanto eu vou ganhar. Só no final do processo é que me interesso pela remuneração.

    Ofereça-se apenas para vagas que você consegue trabalhar

    Esse é o pior tipo. É a famosa metralhadora giratória de curriculums. Parece que o cara tem um filtro no cliente de e-mail que pega e-mails com as palavras “vaga” ou “emprego” e já dá um reply automático com seu curriculum. Quando eu era o dono da empresa e ia contratar eu não só descartava esses curriculums como ainda marcava o nome do indivíduo na lista de “nunca contratar”.

    A vaga é para “desenvolvedor” e não para “administrador de redes”! Se você não consegue ler e interpretar um texto com uma oferta de emprego é bem provável que você também não consiga realizar a tarefa para a qual você seria contratado.

    Se você quer “mudar de ares” comece a estudar sobre “desenvolvimento” e mande esse tipo de informação no seu curriculum e não que você sabe instalar “postfix”, “manutenção de hardware” ou coisas do tipo.

    Se você não sabe se consegue, imagine o contratante

    Se você me manda um e-mail dizendo “Eu programo em Python mas não sei se dou conta de fazer o que vocês fazem” eu (no caso a empresa contratante) devo pensar o que?

    Se nem você sabe se dá conta imagina eu 🙂 Mesmo que eu te conheça pessoalmente e a gente tenha conversado sobre o trabalho é você quem tem que bater no peito e bradar: “Eu consigo!”.

    Então economize o seu tempo e o meu. Se você não tem certeza da sua capacidade não envie e-mail nenhum. Se você sabe que consegue mande direto o seu curriculum e se candidate à vaga.

    Analise a vaga em profundidade

    Antes de mandar o seu belo curriculum pra uma vaga procure saber mais sobre a empresa. Personalize o seu curriculum de forma a deixá-lo mais atraente para a tal vaga. Seja inteligente e perspicaz ao enviá-la (mas por favor polpe-se ao trabalho de inventar moda).

    Eu tenho umas 4 versões do meu curriculum (e uma versão em inglês para cada uma das 4) e sempre pego ele e edito antes de enviá-lo.

    Vamos à uma breve análise dos erros que vi:

    • Página 33 de 150: Não rola, né? 🙂 Se não dá pra resumir as coisas que você fez simplesmente elimine alguns dos empregos que você teve e não acrescentam nada ao seu CV. Por exemplo: eu trabalhei 3 anos em uma agência de publicidade como “publicitário” (ênfase nas aspas). Não preciso colocar isso pra uma vaga de desenvolvedor.
    • Olha a foto! Buuu!: Na mensagem tá pedindo “boa aparência”? Se não tá pedindo significa que tua aparência não importa, certo? Se tua aparência não importa a foto não serve pra nada. Pior: e se você for feio? Num eventual “empate” para a vaga a sua feiura pode te eliminar, mesmo em situações onde ela não seria importante.
    • Mexe com Linux? Pega o .doc: Erro primário esse. Se a vaga fosse pra trabalhar na Microsoft você mandaria seu curriculum no formato .odt? Porque você manda um .doc para trabalhar numa empresa que mexe com Linux? Ok, o OpenOffice “abre” esse tipo de arquivo mas o arquivo .doc mostra habilidade em que tipo de ambiente de trabalho? Na dúvida mande um .pdf, um .txt ou, como eu faço, um .html.

    Eu também uso esse conselho para dizer aos candidatos: inverta o papel de quem escolhe quem. Invista no seu aprimoramento muito mais do que o exigido pelo “mercado” e apresente-se numa situação onde a empresa quer contratá-lo.

    Eu já vi donos e gerentes de empresa fazendo leilão para levar um candidato. Se você é bom o suficiente para estar nessa situação você concordará comigo que é muito mais confortável.

    Mas seja honesto ao ser “leiloado”. Não blefe. Eu já vi ótimos programadores que se queimaram em ambas as empresas porque descobriram o blefe. Acabou sem nenhum emprego e com a imagem arranhada em um mercado onde todo mundo se conhece.

    Você trabalha no emprego perfeito, me aconselhe profissionalmente

    Pessoal, eu não sou o Max Gehringer. O máximo que eu posso dar de dica é para o tipo de trabalho que eu faço. As dicas do Max são legais para casos mais genéricos mas também não precisa levá-lo à sério demais porque senão você acaba virando mais um daqueles candidatos “robôs” cheio de respostas prontas e pré-fabricadas.

    Como teve mais de uma pessoa que me perguntou sobre “investir no aprendizado de Python” eu vou falar um pouco sobre esse caso específico:

    Invista o seu tempo em algo que te deixa feliz. Se você gosta de programar em Python invista em Python. Se gosta de programar mas não importa a linguagem programe em várias delas.

    Se você não gosta de programar? Vai fazer o que você gosta de fazer. Sai fora dessa área. Evite perder o seu tempo e o de outras pessoas que gostam de trabalhar com isso.

    E tem outra coisa: usar o trabalho nessa área como meio para ganhar dinheiro para no futuro atuar em outra área menos rentável. Isso é péssimo. Atue na área “menos rentável” e faça-a se tornar rentável.

    Pega o meu curriculum praquela vaga do mês passado

    Um certo dia eu ofereci uma vaga em uma empresa onde trabalhava que precisava ser preenchida com urgência e recebemos curriculums para essa vaga por mais de 3 meses.

    Se você vê que a oferta foi feita à mais de uma semana desiste.

    Se tiver uma gota de esperança de que a vaga não foi preenchida ou tem “inside informations” de que a vaga não foi preenchida tudo bem. Mas se não for esse o caso fica a lição pra você ficar mais atento.

  • Bluetooth Ponto

    Aqui no INdT a gente tem um sistema de ponto que usa uma etiqueta RFID que fica em nossos crachás para marcar a hora que a gente chega e sai do trabalho. O problema é que esse sistema não é muito confiável e eu também vivo esquecendo de passar o meu crachá na tal maquininha e isso fez com que eu tenha o maior banco de horas negativas aqui da empresa.

    Cansado dessa história eu tentei vários métodos diferentes para marcar a minha chegada e saída aqui da empresa. Usei planilha, adaptei um sisteminha feito por um colega de trabalho, anotei em um caderno… e nada. As anotações estavam sempre inconsistentes e impediam que eu fizesse a conferência do meu relatório de horas e corrigir eventuais problemas.

    Mas isso mudou quando li um artigo que falava sobre um programinha que executa tarefas quando um dispositivo Bluetooth específico se aproximava do computador. Eu pensei: “Eu tenho um celular com Bluetooth e tenho como colocar um dongle Bluetooth na minha estação de trabalho da empresa. Eu posso registrar a minha chegada/saída na empresa baseado na presença do meu celular, afinal ele me acompanha quando chego ou saio do trabalho…”

    Mas o programinha do artigo não funciona com Linux e minha estação de trabalho é Linux então tive que desenvolver o meu próprio script Bluetooth Ponto.

    O funcionamento dele é simples: Quando executado sem nenhum parâmetro ele faz discovery dos dispositivos Bluetooth nas redondezas e registra as entradas e saídas desses dispositivos desde o último discovery. Então é só colocar ele no seu crontab ($ crontab -e) para ser executado de 5 em 5 minutos:

    $ crontab -l
    # m h  dom mon dow   command
    */5 * * * * /path/completo/btponto.py

    Esse comando irá gerar um arquivo de log para cada mês do ano dentro do diretório ~/.btponto e a partir desse arquivo a gente poderá gerar os relatórios.

    Para gerar os relatórios é só criar um arquivinho de configuração com o MAC address do celular e o nome do dono:

    $ cat .btponto/indt.cfg
    [osantana]
    bt = 00:0F:ED:ED:01:02
    name = Osvaldo Santana Neto
    occupation = Researcher

    e roda o btponto.py da seguinte forma:

    $ btponto.py -f .btponto/indt.cfg .btponto/bluetooth-200703.log
    ---------------------------------------------------------------
    Username: osantana
    Fullname: Osvaldo Santana Neto
    BT Mac:   00:0F:ED:ED:01:02
    
    Date        In        Out
    2007-03-20  14:14:00  19:10:12
    2007-03-21  09:35:12  19:20:11
    2007-03-22  08:55:11

    Esse programinha depende do Python BlueZ. No meu Ubuntu Edgy bastou executar: sudo apt-get install python-bluez para instalá-lo.

    Para você descobrir qual o MAC address do teu celular tente:

    $ hcitool scan
    Scanning ...
            00:0F:ED:ED:01:02       meu_celular

    Ou, se o seu celular for um S60 da Nokia digite: *#2820# no teclado numérico.

  • Como aprender inglês sozinho (self-taught)

    Como aprender inglês sozinho (self-taught)

    Eu adoro aprender coisas novas, mas eu gosto de ter o controle sobre o meu aprendizado. Não tenho preguiça de ler nem de ouvir os ensinamentos, mas gosto de poder escolher quando, como e quais deles ouvir.

    Como quase todo mundo eu também tenho preferência em aprender as coisas que eu gosto mais e não gosto de “perder tempo” aprendendo coisas que eu não gosto. Eu coloquei “perder tempo” entre aspas porque acredito que “perder tempo” e “aprender” são dois conceitos que dificilmente andam junto (ou ao menos não deveriam andar junto).

    Pois bem, eu disse tudo isso porque eu não gosto de aprender idiomas. Não importa qual seja. Odiei aprender português enquanto estava na escola e não me esforcei em nada para aprender inglês nas escolas por onde passei (maioria de escolas públicas). Deixei muitos professores revoltados com o fato de que eu não prestava atenção à nenhuma aula e ainda assim conseguia boas notas. Mal sabiam eles que eu estudava a matéria que cairia nas provas. Só que do meu jeito e quando eu queria.

    Já comecei uns 10 cursos de inglês e até aprendi um pouco neles mas depois do segundo ou terceiro mês eu já estava desanimado e desestimulado a continuar. Isso acontece porque eu estou tendo que aprender algo que eu não gosto nas horas que os cursos determinavam e do jeito que eles queriam. Desse jeito não rola.

    Mas e aí? Eu preciso saber inglês no meu trabalho. E muito. Como eu faço pra aprender inglês? Decidi fazer um auto-aprendizado de inglês. E a minha professora seria a a vida offline e online.

    Mas eu não sabia nem por onde começar até que descobri o “poder dos blogs“, dos podcastings e até mesmo dos antigos métodos que usam música e filmes. Coletei alguns deles que listo abaixo e adquiri 3 livros essenciais para o aprendizado do idioma.

    BBC-Logo

    TV

    Assista o noticiário da BBC. Os apresentadores britânicos tem uma dicção melhor e falam mais devagar. É bem melhor para iniciantes do que a CNN 🙂

    Internet / Aplicativos

    A Internet e os smartphones disponibilizam diversas ferramentas de apoio aos estudantes de vários idiomas. Fiz uma pequena seleção dos que mais gosto. Se você tiver outras sugestões envie através dos comentários.

    Duolingo

    duolingo

    Esse aplicativo precisava ter sido inventado antes. Ele é fantástico. Transforma o estudo de inglês em um tipo de partida de “casual game” onde você vai passando de fase, ganhando prêmios (virtuais) conforme aprende um idioma.

    Estudei inglês com ele mas existem outros idiomas. E o melhor: totalmente gratuito (não tem nem que comprar créditos de nada).

    Esse projeto foi criado por um ex-funcionário do Google que usa o imenso contingente de pessoas que jogam o Duolingo para alimentar com dados sistemas computacionais que fazem traduções de documentos.

    English Experts

    Fornece um fórum com muitos usuários que podem te ajudar com diversos problemas. Funciona em um modelo de perguntas e respostas que vai premiando os participantes mais ativos.

    Tecla SAP

    Com um enfoque mais divertido e com histórias engraçadas de pessoas que se deram mal por não saberem inglês é outra boa dica para quem está aprendendo inglês.

    Infelizmente os feeds não funcionam muito bem e não são completos.

    English as a Second Language Podcast

    O mais bem produzido dos podcasts que avaliei é gratuito (exceto se você quiser adquirir o material auxiliar) e tem conversas usadas no dia-a-dia das pessoas seguido de explicações sobre o diálogo.

    Livros

    Os livros que apresento aqui são ferramentas de apoio e consulta nos seus estudos. Nenhum deles ensina inglês mas todos darão suporte aos seus esforços de aprender.

    Oxford Dictionary of Englishoxford-dict

    Um dicionário Inglês/Inglês é essencial. Eu sei que é algo caro mas, acredite, eu já comprei um “Michaelis” e considero o dinheiro gasto com ele perdido. A diferença da qualidade do dicionário Oxford e a sua utilidade justificam o gasto extra.

    Pense também que esse dicionário lhe servirá por toda a vida e que com essas dicas que estou dando você já está economizando bastante dinheiro.

    Oxford Phrasal Verbs

    Eu ainda não tenho esse e por essa razão tenho que ficar emprestando o de um companheiro de trabalho. O número de variantes de phrasal verbs é tão grande que merece um dicionário exclusivo para tratar deles. Phrasal Verbs são aquelas expressões compostas de verbo+advérbio ou verbo+preposição tipo: “break down”, “blow up”, “check in”, etc.

    Inglês + Fácil Gramática

    Essa é uma gramática de consulta rápida. Serve para tirar dúvidas esporádicas sobre gramática. A aquisição deste livro é opcional. É um dos que menos uso apesar de já ter me ajudado algumas vezes.

    Longman Dicionário Escolar Inglês/Português-Português/Inglês

    Esse dicionário não é muito completo mas o “conjunto da obra” torna-o excelente para aqueles que estão aprendendo inglês agora.

    O dicionário português/inglês é extremamente útil para enriquecer nosso vocabulário, os verbetes são fartamente ilustrados, os ‘boxes’ explicativos para expressões e gírias são fantásticos e o preço é excelente.

    Não deve ser o único dicionário em sua casa, mas é um bom começo. Aqui em casa meu filho usa o tempo todo.

    Hábitos Saudáveis

    Além do material indicado acima eu pratico alguns hábitos saudáveis para aperfeiçoar meus conhecimentos em inglês.

    Filmes

    Gosto muito de cinema e tenho o hábito de ver o mesmo filme várias vezes (se o filme for bom, é claro). Quando precisei aprender inglês passei a rever os filmes com a legenda em inglês.

    O áudio e a legenda não são iguais mas as palavras principais estão lá. Como eu já conheço a história (assisti com legenda em português antes) o cérebro passa a assimilar o som das palavras (reforçado pela legenda). Se o filme for realmente bom eu ainda tento assistir mais uma vez sem nenhuma legenda.

    Músicas

    Escute muito à músicas em inglês e, quando se sentir confortável, cante (mesmo no “embromation”) essas músicas.

    Depois procure a letra da música na internet (Google: nome-da-música lyrics) e tente cantar lendo a letra. É impressionante a quantidade de coisas que a gente achava que estava certo e não estavam.

    Traduzir a música pode ser interessante e buscar o significado dela melhor ainda.

    Outros

    • No seu computador: instale tudo em inglês.
    • Participe de grupos de bate-papo em inglês na internet ou em sua cidade. Em cidades maiores é fácil encontrar um grupo desses.

    Pratique

    Não tenha medo ou vergonha de se expressar em inglês mesmo que você ainda não esteja fluente. Lembre-se que o teu interlocutor não deve saber nada de português também 😀 O máximo que pode acontecer é você ser corrigido e aprender um pouco mais (só um babaca te zoaria por falar errado).

    Mais do que ter esse material terei que ter uma grande disciplina para dedicar tempo necessário para estudar.

    Atualização: esse artigo foi praticamente reescrito no dia 2/7/2014.
    Atualização de Links dia 14/06/2022

  • Linguagens de Programação Diferentes: Cada macaco no seu galho

    Linguagens de Programação Diferentes: Cada macaco no seu galho

    Frequentemente encontro com pessoas que já programam em uma linguagem de programação e começam a reclamar de outras linguagens de programação. Falam que a linguagem “Foo” é ruim por causa disso ou daquilo.

    Essas pessoas confundem qualidade com característica. Uma coisa não pode ser considerada ruim simplesmente porque ela é diferente de algo que você gosta.

    Linguagens de programações diferentes são isso mesmo: diferentes. Você não pode esperar que uma linguagem que você está aprendendo agora seja igual à que você usava anteriormente. Se fosse assim você não estaria aprendendo uma linguagem nova, não é?

    Se você usa Java (ou C, ou Pascal, ou …) e gosta muito das características dela, use-a. Se você gosta somente de um subconjunto de características busque uma linguagem que tenha esse mesmo subconjunto de qualidades e que acrescente algo de bom.

    Se você gosta da performance obtida com um programa em C e está disposto a pagar o preço de ter que gerenciar memória “na mão”, cuidar da portabilidade de seu código “na mão”, lidar com ponteiros voadores e vazamentos de memória, colocar “;” no final de cada linha do código fonte, declarar o tipo das variáveis e usar braces, fique com C. Se você gosta disso tudo significa que você não precisa de outra linguagem de programação para trabalhar.

    Se você usa Java, está interessado em empregabilidade, gosta de usar um palavreado recheado de buzzwords, acha que certificações são importantes, gosta de declarar tipo de tudo, gosta de lutar contra o compilador, usa XML até em cartão de visita e gosta de empilhar 50 decorators para abrir um arquivo texto, continue com Java.

    Python é uma linguagem de programação diferente de C e de Java. Até tem algumas semelhanças, mas são poucas. Portanto se quiser aprendê-la tenha isso em mente e não fale mal dela porque ela é diferente.

    Em Python você não usa braces como em C ou Java e isso não faz dela nem melhor e nem pior que outras linguagens. Em Python você também recebe “self” como parâmetro dos métodos e isso não a torna menos OO ou mais OO do que as outras. Também não precisa de “;” no fim de cada linha (e dai?).

    Em Python não precisamos declarar o tipo dos identificadores porque a resolução de tipos é feita em tempo de execução. Isso é diferente de Java, por exemplo, e é pior para alguns casos e melhor para outros. Tem gente que gosta e tem gente que não gosta. Se você não gosta, paciência, porque eu gosto. Java também tem seus “privates“, “protecteds” e “publics” e Python não tem. É pior? É melhor? Nada disso. É diferente.

    Enfim, Python tem seus defeitos e suas virtudes e esse conjunto de características que fazem dela “Python”. Se ela tivesse todas as características de C ela se chamaria “C” e se as caracterísicas fossem de Java ela se chamaria “Java”.

    Além das características sintáticas e semânticas as linguagens carregam consigo uma certa carga de “estilo de programação”. Se você usar o “estilo de programação” C para programar em Python você não vai aproveitar as vantagens dessa linguagem nova.

    Dependendo do caso você vai ter a sensação de que a linguagem é ruim onde na verdade você é que não está utilizando-a corretamente. Portanto antes de criticar a linguagem que você está aprendendo agora, pergunte-se se você está usando ela corretamente. Talvez você esteja martelando um prego com alicate e reclamando que o alicate é uma porcaria.

  • Python está “pronta para o mercado”

    Recentemente li um artigo em um blog que se propunha a vender a idéia de que a pilha “J2EE/Java/Linux” seria a mais perfeita escolha para uma fábrica de software trabalhar.

    Em certo momento do artigo o autor faz uma comparação da plataforma Java que usa quase que exclusivamente a linguagem Java com outras plataformas e/ou linguagens de programação. Neste momento ele explica porque Python não seria uma boa escolha:

    …Python, apesar de ser mais moderna e poder ser compilada, não foge muito deste escopo também. Além disso, ambas (Perl e Python) não conseguiram uma aceitação comercial madura, e, não representando um investimento seguro a longo prazo, não devem ser escolhidas como estratégicas (sic) para a fábrica de SW de uma empresa, ou para um sistema complexo e de missão crítica.

    Esse chavão “…não conseguiram uma aceitação comercial madura…” e suas variantes são sempre repetidas com veemência e numa quantidade extremamente alta. Acho que essas pessoas fazem isso pensando que se repetirem essa mentira ela talvez se torne verdade.

    Se é verdade que não existe empresas do tamanho da Sun, Oracle e IBM que promovam Python da mesma forma que se promove Java também é verdade que existem muitas empresas que usam o poder de Python para concorrer com toda essa força bruta usada pelos javanistas.

    A coisa funciona mais ou menos assim:

    1. você quer produzir software pra ganhar dinheiro.
    2. você pode escolher Java ou Python pra trabalhar
    3. os seus concorrentes já usam Java ha bastante tempo e estão mais adiantados no desenvolvimento de seus softwares
    4. se você escolher Java, você precisa do mesmo tempo que eles para desenvolver o seu software
    5. usar Python te torna mais produtivo1 e consequentemente você levaria menos tempo para alcaçar seus concorrentes e em pouco tempo ultrapassá-los.

    Esse cenário já foi bem descrito por Paul Graham mas os atores envolvidos no tempo em que ele iniciou a empresa dele eram C++ (fazendo o papel da Java) e Lisp (fazendo o papel de Python).

    A dica que eu daria para as empresas que produzem software é: prestem atenção em Python e experimentem-na. Eu garanto que depois de usá-la você vai querer mantê-la como “segredo de negócio” para seus concorrentes, algo como uma “arma estratégica” contra eles.

    E se você não gostar de Python também pode experimentar Ruby porque com qualquer uma dessas você certamente produzirá muito mais e melhor do que usando Java/J2EE. E se isso não for verdade eu publico o seu case de insucesso aqui neste blog e dou o meu braço a torcer.

    Por último: Cobol, Clipper e Delphi já foram as linguagens que todos diziam ser “maduras para o mercado”. Pense nisso.

    1 Existem várias formas de comprovar essa afirmação mas todas elas são extensas demais para este blog. Convido os interessados a pesquisarem sobre essa afirmação na Internet ou com empresas que já assumiram publicamente que usam Python.

  • Software Livre: você contribui com código?

    Desde antes do Linux surgir ou da idéia de Software Livre ser conhecida entre as pessoas aqui no Brasil eu já era defensor deste modelo. Quando eu desenvolvia meus sistemas em Clipper para os meus clientes tratava logo de deixar o código fonte com eles e já deixava claro pra eles que se eles preferissem entregar a manutenção para outro desenvolvedor eles estariam livres para fazê-lo.

    Discurso padrão: serei um pouco contundente em alguns trechos deste artigo. Farei algumas generalizações para facilitar mas, acredite, alguns brasileiros simplesmente não se encaixam no público alvo deste artigo.

    Ok, essas liberdades que eu dava para meus clientes não chegavam nem perto das reais liberdades que os softwares licenciados pela GPL, por exemplo, oferecem hoje. Mas as minhas intenções eram as mesmas.

    Desde que entrei de cabeça neste universo livre percebi que todos esses softwares que existem hoje foram ao menos iniciados a partir de esforços voluntários de uma comunidade de desenvolvedores, artistas, documentadores, etc.

    Esses voluntários estão espalhados por todos os lugares do mundo inclusive no Brasil. E é sobre a participação brasileira que gostaria de comentar.

    Atendendo à um pedido de um colega de trabalho comecei a fazer uma pequena pesquisa informal e não-científica sobre a participação de brasileiros no desenvolvimento de software livre e fiquei muito feliz em ver que esses brasileiros contribuem com vários projetos. Obviamente ainda é uma fração praticamente irrisória de contribuições se compararmos com países da europa, por exemplo, mas já é alguma coisa.

    Essa pequena pesquisa também serviria para coletar alguns nomes de profissionais que fizeram alguma colaboração com código para algum desses projetos para buscar alguns talentos para vir trabalhar comigo na mesma empresa onde trabalho.

    Aí veio a decepção. Infiltrando mais à fundo nas colaborações desses brasileiros foi possível notar que a contribuição nossa com código para esses projetos é tão pequena que faz qualquer um ficar decepcionado.

    É claro que contribuir com documentação, traduções, arte, divulgação e uso é importante para esses projetos. Mas e o código? Software Livre não se cria sozinho! Você não liga um computador e o código pula na tela. Não é tão simples assim.

    Sempre que eu falo que precisamos colaborar com código para os projetos já escuto logo um: “ah… mas eu traduzi o sistema foobar para o português!” ou “eu fiz um tutorial de instalação da distro ble”. Legal. Parabéns! Mas e aquele bug aberto no bugtrack do sistema foobar? E aquela funcionalidade que as pessoas estão implorando (inclusive você)?

    Vamos esperar até o dia que o bug se feche sozinho? Ou que o desenvolvedor principal do projeto use o tempo dele para melhorar a minha vida?

    Chegou a hora de parar de nos desculpar por não contribuir com código para os projetos simplesmente porque “eu traduzi as mensagens de erro do kernel!” e começar a anexar patches e fazer commits nesses projetos.

    Eu me incluo entre esses “colaboradores de meia pataca”. Procurei pelo meu nome no Code Search do Google e achei um horror o resultado. Afinal já fazem mais de 6 anos que lido com Software Livre e meu nome apareceu em apenas algumas dezenas de ocorrências e, pior, em menos de uma dezena delas a minha contribuição tinha sido com código.

    Então eu gostaria de lançar o desafio aqui: vamos todos repetir uma busca por nossos nomes no Google Search daqui a algum tempo e vamos ao menos dobrar o número de ocorrências deles por lá? Mas só vale contar contribuições com código!

    Propaganda: Se você quer contribuir com código e quer começar por uma linguagem fácil e poderosa eu já recomendo à você que dê uma olhada na linguagem Python 🙂

  • Regulamentação da nossa profissão

    Esse é o assunto polêmico do momento. Parece que se fala disso em todos os sites de tecnologia do momento mas acredito que a minha opinião sobre esse assunto ainda não apareceu em nenhum deles.

    Por essa razão vou escrever a minha opinião sobre o tema aqui no meu blog para que as pessoas que pensam o mesmo que eu possam se manifestar sobre o assunto.

    A minha opinião sobre a tentativa de regulamentar as profissões ligadas à informática é: eu não me importo.

    Sério. Eu não me importo se a profissão na qual eu trabalho vai ser regulamentada ou não. Porque eu não me importo com isso? Porque eu estou me formando e já trabalho a mais de 5 anos na área. Para as pessoas nessa situação nada vai mudar.

    O cenário onde nossa profissão não é regulamentada é o que vivemos hoje, logo, não vou me alongar muito nas explicações sobre ele e falarei mais sobre o cenário hipotético onde a regulamentação exista.

    Hoje um profissional da área que busca o seu lugar no mercado de trabalho se apresenta aos pretensos contratantes munido de todo o seu histórico profissional, ‘luta’ contra os outros candidatos e, no final, ganha ou perde a batalha (ou emprego).

    Na ponta do contratante as variáveis usadas para escolher um candidato para a vaga aberta são muitas. Tem empresa que pede diploma, outras pedem *um bom diploma* e outras nem pedem um diploma. Algumas outras pedem certificações caras, outras pedem certificações baratas e algumas não pedem certificação. Algumas pedem experiência, outras pedem exageros de experiência e outros exigem inexperiência(!).

    Mas tem algo que o contratante pede que é sempre uma constante: qualidade. A qualidade é uma característica ortogonal à todas as outras já mencionadas. A falta dela também. Então existem profissionais bons diplomados e não diplomados, Profissionais ruins certificados e não certificados e todas as outras combinações possíveis.

    No cenário onde a regulamentação existe teríamos um grupo só com os profissionais diplomados ou com algum tempo de experiência que seriam carimbados com o selo “Regulamentado!”.

    Pois bem, em que isso mudaria a vida dos contratados? Se eu não sou ‘regulamentado’ eu só conseguiria empregos onde a ‘regulamentação’ não é necessária restringindo aí as suas chances de ser contratado. Se ele for um bom profissional ele vai numa dessas ‘uniníquel’ estuda uns 2 ou 3 anos lá, pega um ‘canudo’ e grampeia junto com o Curriculum e tudo está resolvido. Só não pode esquecer de pagar a mesada para o órgão da categoria que seria criado à reboque da regulamentação.

    Se o profissional não-regulamentado for muito bom *mesmo* e uma empresa o recusa por essa razão o azar é da empresa. Ela que se dane sozinha. Sorte do profissional também por não ter que trabalhar em uma empresa que considere o carimbo de “Regulamentado!” mais importante do que as qualidades do profissional.

    Os profissionais regulamentados tem a ilusão de que com a regulamentação deixará de existir a concorrência desleal dos “Sobrinhos do Tio” que fazem um trabalho meia-boca por ‘délão’. Se fosse assim não teríamos mais abortos clandestinos no país, muito menos venda de medicamento sem receita, etc.

    Não podemos nos esquecer que as empresas que querem pagar pouco sempre vão pagar pouco não importando se o profissional é regulamentado ou não ou se a qualidade do trabalho será boa ou não (Vale lembrar que a regulamentação também não garante a qualidade do serviço).

    E na vida dos empresários, o que mudaria? Pouca coisa também. Se ele contratar um profissional regulamentado e o serviço for ruim o que acontece? Denunciá-lo por maus serviços é o mesmo que denunciar um médico por erro médico: você pode até ganhar alguma recompensa, mas o estrago já foi feito.

    E se ele não faz questão de ter um profissional regulamentado ele vai contratar essa pessoa de qualquer jeito. Mesmo que seja para registrá-lo como ‘lavador de pratos’. Se eu fosse empresário eu não daria a mínima importância para o carimbo de “Regulamentado!” de um profissional porque estaria restringindo as minhas alternativas de contratação e fazendo isso quantos bons profissionais não-regulamentados eu estaria perdendo?

    Eu faço faculdade e sei que isso não atesta a qualidade de um profissional. Também já fiz certificação e sei que isso também não atesta a qualidade de um profissional. Não vai ser um carimbo “Regulamentado!” que fará isso ser diferente.

    E se a regulamentação não vai mudar em nada porque eu deveria me preocupar com ela?

  • Python import

    Ao começar a trabalhar no desenvolvimento do Python para Maemo no INdT a gente percebeu que o CPython não apresentava problemas sérios de performance no 770 e que uma das poucas coisas que realmente incomodava era a demora para importar alguns módulos importantes na plataforma (principalmente o PyGTK).

    Quando iniciamos a segunda fase do nosso projeto decidimos atacar a otimização da plataforma Python em duas frentes: uma na linha de pesquisa que daria resultados a longo prazo e uma outra com foco mais prático no CPython.

    Eu assumi a segunda linha enquanto o Rafael Espíndola, que trabalha com a gente, assumiu a linha mais acadêmica (além de me dar uma ajuda valiosa com alguns testes que requerem mais conhecimento técnico). Esse trabalho envolve a criação de um backend ARM para o LLVM e posteriormente melhorar o backend LLVM do PyPy para que com essas duas ferramentas seja possível gerar código binário nativo para ARM a partir de código fonte Python.
    Como o maior problema de performance do CPython no 770 era relacionado ao carregamento de módulos resolvi atacá-lo primeiro e para atacá-lo fui entender como ele funcionava. Não gostei muito do que vi.

    Aparentemente o sistema de ‘import’ do Python nunca recebeu uma atenção muito grande e desde o começo ele vem recebendo patches em cima de patches. Muitas funcionalidades foram adicionadas sem muito planejamento ou, por manter compatibilidade retroativa, tiveram implementações pouco elegantes.

    Decidi então fazer uma reforma nesse sistema tentando deixá-lo mais elegante e ao mesmo tempo não tentar quebrar compatibilidade retroativa gratuitamente.

    Como estou interessado nessa parte do desenvolvimento do CPython eu me ofereci para ajudar o Brett Canon em uma das tarefas propostas para o Python Google Sprint. Infelizmente o Brett tinha outras prioridades para esse Sprint e pode se oferecer apenas para me ajudar quando eu precisasse. O Guido, por sua vez, também pediu para eu adicionar meu nome na tarefa.

    Durante o período do Sprint eu desenvolvi um esboço (bem inicial, incompleto e agora totalmente perdido em algum backup velho.) do que eu planejava para que eles pudessem entender que rumo eu gostaria de seguir.

    Mostrei o meu trabalho para o Brett e ele me diz que o que ele planejava era algo bem mais simples que serviria já para o 2.6 e consistia apenas em reescrever a função __import__() em Python e que o meu plano era maior e certamente não seria aceito para a série 2.6.

    Me apontou também a PEP-302 onde algumas das minhas idéias já foram discutidas e não foram aceitas (principalmente por adicionarem incompatibilidade retroativa). E disse que como os nossos planos eram muito diferente ele iria trabalhar nos planos dele mas que continuaria me ajudando se eu precisasse.

    A sensação que eu tenho é a de que eu devo seguir adiante com esse plano meu nem que seja para facilitar o nosso trabalho no Python para Maemo. Depois que tudo estiver pronto e funcionando eu vou escrever uma PEP e submeter na lista python-3k.

    Se for aceito, legal. Se não for, paciência. Só espero que eles entendam o que eu quero com esse projeto e não façam como fizeram com o Gustavo Niemeyer quando ele propôs a inclusão do dateutil na biblioteca padrão do Python (por não terem entendido a proposta do módulo optaram por miná-la ao invés de entendê-la).

  • ITopia

    Trabalho na área de informática há muitos anos. Sempre trabalhei com desenvolvimento de software, exceto por um período de tempo quando tentei seguir a carreira de publicitário por estar um pouco decepcionado com o trabalho na área de programação de computadores.

    A minha desilusão nasceu com o tipo de trabalho que um programador, aqui no Brasil, mais faz: software de gestão empresarial. A capacidade criativa que o brasileiro desenvolveu nesse tipo de desenvolvimento causa inveja em diversos países do mundo. Isso é bacana.

    Esse tipo de desenvolvimento nunca foi meu preferido mas eu devo admitir que sempre foi o que fizemos de melhor.

    Mas de um tempo para cá eu venho notado que as empresas de desenvolvimento de software estão procurando buscar modelos de desenvolvimento de software vindos de fora. Opa! Se esse é o tipo de coisa que sempre fizemos bem aqui não deveríamos estar exportando?

    O modelo de empresa de desenvolvimento que me deixa mais horrorizado é o triunvirato formado por engenharia-de-software, fábrica-de-software, STLs (sigla-de-três-letras como CMM, RUP e PMI).

    Quando eu estudava Processamento de Dados em um colégio técnico estadual no interior de São Paulo eu tinha vários amigos que estudavam ‘Edificações’ que forma profissionais preparados para auxiliar os Engenheiros Civis. Alguns alunos amigos meus eram tão bons em seus trabalhos que os engenheiros somente ‘assinavam’ os projetos feitos por eles.

    Se nessa época a minha visão-além-do-alcance me mostrasse o que está acontecendo hoje eu iria estudar Edificações e não mais Processamento de Dados. Estou esperando o dia que vão surgir os decoradores de sistemas, afinal, os engenheiros de software e arquitetos de software já existem.

    Esse triunvirato parte da premissa de que software é algo criado em cima de padrões, normas e requisitos e esquecem de que essas três coisas produzem software mas nunca irão produzir software fantástico. O que diferencia um software de um software fantástico é o ‘toque de genialidade’ dos desenvolvedores. É aquela modificação elegante no código que o torna mais eficiente. É aquela idéia simples que torna o sistema mais robusto. É aquele momento de inspiração que faz surgir um excelente software. É aquela fuga do padrão, da norma, e até mesmo do requisito que fazem um software virar um software fantástico.

    Os softwares de gestão brasileiros são (eram?) fantásticos por essa razão. Antes as normas eram menos rígidas, os padrões menos abrangentes e os requisitos quase sempre eram desconhecido. Sei que muito software ruim foi produzido naquela época mas tolher a criatividade não deve ser a solução para esse problema. Que solução então? Seleção natural. É isso. Software ruim ‘morre’ com o passar do tempo. Software que nasce ruim mas melhora com o passar do tempo sobrevive.

    Para resumir, o desenvolvimento de software é, em minha opinião, muito mais uma atividade criativa do que simplesmente aplicar técnicas, regras, normas em cima de um teclado de computador.

    Minha forma de pensar leva à uma outra questão importante a ser ponderada: Programador sem criatividade deve mudar de profissão? Sim e não.

    Se ele está nessa área porque disseram para ele que “programador é a profissão do futuro” sim. Todas as pessoas devem fazer o que gosta e não o que disseram para ela fazer. Trabalhar com algo que não te inspira cria pessoas tristes. E não vale falar que vai continuar programando porque ‘não agrada nem desagrada’, tem que gostar mesmo de trabalhar.

    Mas se esse programador ‘não-criativo’ realmente tiver paixão pela profissão que vai exercer o problema de criatividade dele pode ser solucionado.

    “Moço! Me vê 2kg de criatividade?”

    As pessoas acham que um ‘insight criativo’ é o resultado de um sopro de pó de pirlim-pim-pim que a Fada Sininho jogou na gente. Isso não é totalmente verdade (exceto talvez pela fada).

    Os ‘insights criativos’ são criados pelo nosso cérebro o tempo todo (em momentos randômicos). O nosso cérebro então coleta uma série de informações dos nossos ‘bancos de memórias’ de acesso rápido (informações), acesso lento (conhecimento) e do disco (lembranças), bate tudo por uns minutos no liquidificador e joga no ‘pipeline’ de coisas em processamento. O resultado dessa mistura, se for bom, será aproveitado, caso contrário será descartado imediatamente.

    Com essa explicação podemos perceber que uma série de fatores aleatórios que determinam se você terá um ‘insight criativo’.

    Quando você vai apostar na mega-sena (ou outro jogo desse tipo) você sabe que quanto mais números você marcar no canhoto de apostas maiores serão as suas chances de ganhar o prêmio. O mesmo acontece com nosso cérebro. Quanto mais informação, conhecimento e lembranças a gente tiver para que o nosso cérebro trabalhe maiores são as nossas chances de ter uma idéia legal.

    E é aí que entra o fator ‘paixão’ pela profissão. Se você for apaixonado pelo que faz será mais fácil para você ler um livro sobre o assunto, fazer um treinamento, prestar atenção às informações relacionadas ao teu trabalho e assim por diante.

    É claro que existem alguns programadores que são absurdamente geniais e criativos, mas eles são uma exceção (boa) e não são reproduzíveis em laboratório.

    Tem que ter técnica!

    Dizer que o importante é ser criativo não pode levar ninguém a concluir que a técnica é dispensável. Não é mesmo. A técnica é tão importante quanto a criatividade. Ambas devem ser desenvolvidas por igual e nutridas da mesma maneira. A técnica fornece elementos para que a loteria criativa do cérebro crie coisas legais que, através da técnica irão virar realidade; um ciclo fechado.

    Não pense que Da Vinci usou só de criatividade para pintar a Monalisa. Se ele não tivesse conhecimento de sombras, luzes, cores, anatomia, etc. certamente ele não teria criado essa obra de arte.