osantana

Categoria: Geral

  • I Has Arduino!

    I Has Arduino!

    Hoje de manhã chegou uma encomenda pelo correio que eu estava esperando a muito tempo: meu Arduino 🙂 Quando eu tinha uns 9/10 anos de idade eu adorava ‘brincar com eletrônica’ com um amigo meu que tinha uma oficina em seu quintal. Todo dia depois da aula a gente jogava Atari na minha casa e depois ia para o “laboratório” dele montar os projetos que saiam nas revistas Experiências e Brincadeiras com Eletrônica Júnior ou na Be-a-Bá da Eletrônica.

    Certo dia esse amigo meu me chamou na casa dele porque ele tinha acabado de ganhar um computador. Era um MSX Expert 1.1 da Gradiente completamente sem acessórios. Quando ele ligou o computador e começaram os primeiros acordes do cartucho de demonstração (Ligue-se ao Expert) eu pensei: “É isso o que eu quero pra minha vida”.

    Era exatamente um desses

    O processo de programação na época era +/- assim:

    10 CLS
20 ON ERROR GOTO 70
30 PRINT "DESLIGANDO O ATARI DA TV E LIGANDO O EXPERT"
40 PRINT "COPIANDO PROGRAMA DO LIVRO..."
50 PRINT "EXECUTANDO O PROGRAMA (RUN)"
60 PRINT "PARABENS! DELIGUE O COMPUTADOR E PERCA TUDO"
70 END
80 PRINT "CORRIGE OS ERROS"
90 GOTO 50
RUN

    Mas não foi pra falar disso que eu criei esse post. Vamos voltar ao assunto.

    Enquanto morava em Recife o Elvis Pfützenreuter me deu alguns componentes eletrônicos que ele tinha comprado para usar em uma maquete de ferromodelismo que ele tinha desistido de continuar. Isso me fez lembrar de como era bom o cheiro de solda e decidi retomar a eletrônica como Hobby.

    Ainda estou aprendendo!

    Assim como na computação as coisas evoluiram nos últimos anos com a eletrônica também. Então “aquela” eletrônica que eu conhecia onde a gente usava só uns transistores, uns resistores, uns capacitores, etc… se transformou em algo muito parecido com… informática!

    “Brincar” com eletrônica nos dias de hoje quase sempre te levará a usar um microcontrolador, ou seja, você terá um chip programável com software para trabalhar.

    E é aí que o Arduino entra na história.

    O Arduino é um hardware com especificação livre e possui várias implementações diferentes mas todas elas possuem um microcontrolador Atmel instalado. Como o projeto é aberto existem diversas extensões e projetos que usam ele tal no universo do software livre.

    A idéia do hardware livre é tão semelhante à do software livre que existem comunidades formadas em torno destes projetos. As idéias se intercalam também. Para ver isso basta olhar para a IDE utilizada para programar o Arduino. Usa o GCC como compilador e a IDE tem uma implementação livre feita em Java.

    Se você, como eu, tem interesse nesse universo e quiser adquirir uma placa Arduino pra ‘brincar’ é só fazer uma visita no site da Symphony e comprar um. O modelo que eu tenho aqui é o de 16K:

    I Haz Ardooino!

    Update: Esqueci de agradecer ao Blog do Jê que é um dos “praticantes de Arduino” no Brasil e notíciou o lançamento da placa pela Symphony (que tornou a compra mais $acessível$)

  • Cross-compiling fácil fácil

    Como eu já contei no post anterior no meu novo trabalho a gente tem que lidar com cross-compiling (compilação cruzada) o tempo todo. A idéia da compilação cruzada é simples: você compila um programa P em uma plataforma A e o binário produzido deverá rodar em uma plataforma B.

    O conceito é simples, o seu funcionamento na teoria também. Para compilar um típico programa Linux em um computador x86 para rodar na plataforma ARM bastaria ter o toolchain, que é o conjunto de ferramentas que engloba o binutils (onde fica o linker) o gcc (onde fica o compilador C/C++) e em algumas bibliotecas básicas já como binários ARM (a libc é uma delas).

    O problema do ovo e da galinha dificulta um pouco a construção de um toolchain (você precisa compilar o compilador) mas não é incomum que esses toolchains já sejam distribuídos com a plataforma ‘alvo’, logo, esse problema não é muito grande.

    Com cross-toolchain já instalado a teoria diz que bastariam os seguintes comandos (assumindo que a nossa plataforma alvo seja ARM) para compilar um programa:

    $ ./configure --host=arm-linux
$ make
$ make install

    Com algumas pequenas variações disso conseguiríamos fazer a compilação cruzada de ‘todo o Linux’, mas na prática a teoria não funciona… 🙂

    O que acontece é que um grande percentual das aplicações (regra e não exceção) simplesmente ignora o fato de que no futuro elas serão submetidas à compilação cruzada e simplesmente não funcionam nessas circunstâncias.

    O Python é um desses programas. O interpretador compila perfeitamente, mas as extensões em C da biblioteca padrão não. O problema é que o Python usa o módulo distutils para executar tal tarefa e o mesmo é feito em Python. Neste caso precisamos de um Python ARM para executar a segunda fase do processo de build. Como executar um Python ARM em uma máquina x86?

    Uma das maneiras é compilar primeiro um interpretador Python x86, renomeá-lo para algo como ‘hostpython‘, depois compilar um interpretador Python para ARM e aplicar uns patches no Makefile.in do Python para que ele chame o ‘hostpython‘ para compilar as extensões C. Mas os efeitos colaterais dessa solução são enormes porque existem extensões que usam bibliotecas do sistema (OpenSSL, Socket, SQLite, …) e o distutils não irá procurá-las no lugar correto pois não sabe o que é compilação cruzada.

    Aí então entra uma técnica de transparência de CPU que aprendi a fazer com a turma do projeto Scratchbox (aperfeiçoada pela turma do projeto Mamona) que é bem simples e permite fazer compilação cruzada sem modificar nada nas aplicações que estão sendo compiladas.

    A idéia é usar o binfmt do Linux para dizer que todos os binários ARM deverão ser executados pelo qemu (pegadinha 1: esse qemu deve ser estático e estar instalado dentro do chroot no path definido nas configurações do binfmt) e criar um ambiente chroot com tais binários.

    Dentro desse ambiente todos os binários ARM rodam com o qemu e todos os binários x86 rodam nativamente na sua plataforma (assumindo que ela é x86) sem que você sequer note a diferença entre o funcionamento deles. Desta forma podemos colocar então o nosso cross-toolchain dentro desse chroot fingindo ser um toolchain nativo ARM (tem uma pegadinha aqui: esse toolchain precisa ser estático e não dinâmico pois as bibliotecas nesse nosso ambiente são ARM e não mais x86).

    Você está me perguntando “porque não compilar um toolchain nativo pra rodar dentro desse chroot“? Só por questão de velocidade. O gcc rodaria muito devagar sendo emulado pelo qemu.

    Agora é só sair compilando os programas normalmente. Mesmo aqueles que não estão preparados para compilação cruzada:

    $ ./configure
$ make
$ make install

    Neste exato momento estou compilando o SQLite3 (após ter terminado o OpenSSL) dentro do ambiente chroot com binários ARM (XScale) que rodam emulados pelo qemu. Tudo isso para que no final eu tenha um Python com Pygame 100% funcional.

    Ok. Agora é a hora das notícias ruins:

    • O qemu não emula 100% das syscalls, logo, você poderá esbarrar com uma das famigeradas mensagens “Unsuported syscall XX“. Nestes casos verifique se já não existe um patch que implementa o suporte à essa syscall no qemu e recompile-o (lembrando que o qemu precisa ser estático).
    • O qemu não lida muito bem com threads, logo, se os scripts de build do seu programa testam threads eles podem quebrar (ou bloquear). Neste caso a sugestão é: retire esses testes dos scripts e assuma que sua plataforma tem sim (ou não) suporte à threads.
    • Lembre-se sempre que o kernel não é emulado pelo qemu! Se o seu programa usa ferramentas como o uname, por exemplo, ele irá retornar informações da sua plataforma nativa e não da plataforma emulada. Desenvolvimento para o kernel também não é muito viável.
    • Pode acontecer da tua aplicação quebrar ‘silenciosamente’. Lembre-se que pode ser o qemu quebrando e ocultando a real causa do problema. Nesses casos utilize as funções de depuração do qemu.
    • Lembre-se de ter o /proc e o /sys montados dentro do seu chroot. Alguns programas usam as informações disponíveis nesse lugar para a sua construção. Lembre-se também que esse /proc e /sys são da sua plataforma nativa e não da plataforma emulada, logo, eles poderão fornecer informações incorretas.
    • Dica: tenha a sua área de trabalho ($HOME) montada via mount --bind dentro de seu chroot para que você possa ter vários chroots compartilhando o mesmo $HOME.
  • Ambiente Isolado para Python com virtualenv

    Ambiente Isolado para Python com virtualenv

    Boa parte do meu dia-a-dia de desenvolvedor é gasto em proramando em Python. Gosto de estar sempre atualizado com o que há de novo para essa linguagem e para isso saio instalando tudo o que aparece para para experimentar. Além de Python o Linux também faz parte da minha vida e uso ele quase 100% do meu tempo (em vias de mudar para o OS X).

    O conteúdo deste artigo está desatualizado e ele é mantido aqui apenas por motivos históricos.

    A plataforma Python, de uns tempos pra cá, vêm padronizando os arquivos Eggs para distribuição de aplicações e bibliotecas. Em conjunto com o PyPI (Python Package Index) e o utilitário easy_install (que é parte do framework setuptools) é possível instalar componentes Python com apenas um comando.

    A facilidade para instalar esses pacotes é enorme mas removê-los é chato porque envolve a edição de alguns arquivos texto, e ter permissão de escrita no diretório de bibliotecas do Python (permissão que também é necessária para a instalar o pacote).

    Cada pacote instalado acrescenta uma entrada ao sys.path do Python fazendo com que o tempo para importar um módulo aumente um pouco mais (cada uma dessas entradas é consultada em busca do módulo e se você der uma olhada na saída do strace verá que a procura por um módulo envolve vários passos).

    O Linux que eu uso (Ubuntu) precisa ter um ambiente Python estável, já que grande parte de suas aplicações roda em cima dessa linguagem, ou seja, danificar esse ambiente pode atrapalhar todo o funcionamento do sistema.

    Isso tudo junto com o fato de que adoro experimentar as novidades do mundo Python faziam com que meu Python ficasse totalmente poluído com versões bleeding edge de bibliotecas que muitas vezes são incompatíveis com as versões “oficialmente suportadas” pelo pessoal que faz o Ubuntu.

    Seria necessário um jeito fácil de se criar ambientes isolados do Python usando como base a própria instalação do sistema para que eu pudesse fazer esses testes e experiências sem danificá-lo. Não ficar replicando cópias de Python pela máquina também seria interessante.

    E então surge a solução…

    Parece engraçado mas no mesmo dia que perdi horas “arrumando” o Python em meu computador eu li no blog do Ian Bicking que ele tinha desenvolvido um programinha que fazia exatamente o que eu precisava: o virtualenv.

    O uso do virtualenv é extremamente simples e direto. Basta instalar, executar e ativar.

    Instalação

    Se você está usando Ubuntu ou Debian:

    sudo apt-get install python-setuptools
sudo easy_install virtualenv

    Se não está:

    wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

    Criando o ambiente

    Para criar um ambiente basta executar o virtualenv e passar como parâmetro o nome do diretório onde tal ambiente será instalado:

    virtualenv meu_python

    Esse comando irá criar um diretório chamado meu_python com os diretórios:

    • bin – executável do interpretador, o script easy_install e o arquivo activate que será usado para “ativar” o ambiente. Quando o ambiente está “ativo” os executáveis dos aplicativos Python são instalados aqui também.
    • lib – a árvore com links simbólicos e/ou cópias de todos os módulos e bibliotecas do Python. Quando esse ambiente está “ativo” os módulos e pacotes serão sempre instalados dentro desse diretório.
    • include – dentro desse diretório estão os links simbólicos para todos os headers do Python que são necessários para se compilar extensões escritas em C para ele.

    Ativando o ambiente para usar

    Para usar esse ambiente recém-criado é necessário ativá-lo. para isso basta executar o seguinte comando:

    source meu_python/bin/activate

    Esse comando irá adicionar o diretório meu_python/bin no PATH da sua sessão e mudar o prompt para que você possa distinguir visualmente quando este ambiente está ativo.

    Atenção: O virtualenv não cria o link simbólico python -> python2.5, portanto, se precisar dele você terá que criá-lo à mão com o seguinte comando

    (cd meu_python/bin; ln -s python2.5 python; hash -r)

    Depois disso é só sair instalando as coisas sem a menor preocupação.

    PS. Eu não testei o virtualenv no Windows nem no Mac OS X mas no site do projeto é possível notar que tem gente usando ele também nessas duas plataformas, portanto, eu acho que ele também funcione corretamente nelas.

  • $oftware Livr€

    Pra não dar muito trabalho pra escrever esse artigo não vou ficar fazendo links para a discussão que se iniciou com um post sobre o modelos de negócios com SL. Para quem quiser mais detalhes sigam os links do br-linux.org.

    Esse artigo é antigo e já não reflete a minha opinião pessoal. Mantive aqui apenas para registro histórico.

    A referência que fiz ao meu apelido ‘xiita’ induz o leitor a entender que isso é sinônimo de ‘radical’. O tempo e o estudo me mostraram que nada poderia estar mais longe da verdade. Xiitas são uma vertente do islamismo e, como tal, prega a tolerância e a paz.

    Osvaldo

    O Software Livre apareceu na minha vida a partir do ano 2000 quando fui contratado pela Conectiva S/A (Mandriva) para integrar a equipe de P&D e trabalhar no desenvolvimento do Conectiva Linux. Poderia dizer que eu já mexia com isso antes mas estaria exagerando já que o máximo que eu fazia era disponibilizar os códigos fonte de meus softwares (feitos em Clipper Summer’87 :)) para meus clientes. São só 8 anos mas tempo o suficiente para entender e ver muitas coisas acontecerem.

    De 2000 pra cá passei por muitas empreitadas e passei por lugares onde recebi apelido de ‘xiita’ (por causa do entusiasmo pelo SL) e sou tratado como ‘traidor do movimento’ quando digo que sonho em ter um Apple rodando OS X.

    Fazendo uma retrospectiva por todos esses 8 anos eu posso perceber uma certa coerência entre meus ideais e minhas atitudes. Evidentemente algumas idéias mudaram e outras atitudes também mas a essência permaneceu a mesma: Eu gosto de software bom.

    Ser livre ou proprietário é só um dos critérios (importantes) que uso para avaliar a qualidade de um software. Se eu gosto de um software proprietário e acho que o valor cobrado por ele é correto eu certamente pagarei. Já comprei licenças de software para meu antigo Palm, licença para o Nero Burning ROM, anti-vírus NOD32, e até mesmo a do Windows OEM que veio com meu Notebook (nesse caso eu não acho o software bom, mas ele era necessário para rodar o Nero :))… mas jamais comprarei uma licença do Microsoft Office (detalhe: sou fanático por planilhas eletrônicas desde o 1-2-3 e acho o Excel a melhor planilha que existe atualmente).

    Eu também tenho alguns softwares piratas rodando na máquina com Windows (principalmente a alternativa ao GIMP :P) e isso é algo que me deixa desconfortável pois sou daqueles radicais que acham que pirataria é contravenção. Prometo adquirir esse software assim que surgir uma promoção para estudante (ele é muito caro mas vale o preço).

    O critério do software bom serve para definir minhas escolhas no uso de um software mas faço toda a força do mundo para que os softwares que desenvolvo sejam Livres ou, no mínimo, OpenSource. Mesmo que seja um software desenvolvido no trabalho. Meu histórico de desenvolvimento de sofware livre é pequeno e nenhum deles “emplacou” mas isso não fez com que eu deixasse de acreditar no modelo pois, afinal, eu os desenvolvo principalmente para os meus propósitos (ou para os propósitos da empresa onde trabalho). Se outros acharem útil e quiserem colaborar ótimo mas caso contrário está bom também.

    É muito difícil ganhar dinheiro desenvolvendo e vendendo software livre e quando esse dinheiro começa a entrar nunca estará na mesma proporção da entrada financeira de um software proprietário. Mas ao tentar ganhar a vida “vendendo” software o autor precisará muito mais do que código para se sustentar. Ele precisará de muita criatividade, muita paciência, um bom planejamento, uma pitada de sorte e uma visão realista do mundo.

    Idéias não faltam para que isso dê certo e muitas empresas espalhadas pelo mundo já comprovam isso, mas no Brasil a coisa ainda é um pouco mais complexa pois uma série de fatores como educação deficiente, preguiça, ‘malandragem/jeitinho’, ‘lei de Gerson’ e muito discurso dificultam o desenvolvimento de um modelo baseado no SL aqui no Brasil.

    O próprio autor do manifesto citado no artigo do br-linux.org era um dos que passavam horas escrevendo seus “e-mails-discursos” ao invés de trabalhar no desenvolvimento de seu software. O software que ele desenvolveu também poderia ter sido feito em forma de colaboração para outros projetos (plugin pro Webmin?) mas não foi. Como um desenvolvedor pode querer colaboração para seu projeto se nem ele foi capaz de (ou se interessou em) colaborar com outro projeto?

    Com relação à contribuição e à comunidade brasileira de SL: esqueça. A comunidade brasileira de desenvolvedores de SL é quase uma obra de ficção. O brasileiro quer “parasitar” o software livre. Ele quer usar o software “de graça” e não fazê-lo ou melhorá-lo. É evidente que temos grandes excessões mas elas servem apenas para confirmar a regra.

    Os brasileiros acham que usar SL e ficar repetindo as palavras do Stallman bastam, mas esquecem que software é feito de código e que sem ele nada vai existir ou melhorar.

    Portanto os meus conselhos para quem quiser se envolver com o desenvolvimento de SL são:

    1. colabore com algo que já exista!
    2. se não existir ou não for possível colaborar: faça!
    3. faça mais!
    4. escreva, documente e desenvolva em inglês. Não use a língua portuguesa para não limitar os seus colaboradores a 0.
    5. lance o software (divulgue-o em todos os lugares possíveis).
    6. use-o.
    7. não espere nada em troca.
    8. não espere nada em troca mesmo (principalmente de brasileiros).

    Acredite, você será recompensado.

    Update: Eu reli o meu texto depois de publicá-lo e percebi que, apesar de ter citado a existência de desenvolvedores brasileiros que colaboram com SL, eu não dei a ênfase necessária (e até peguei um pouco pesado demais). Pois bem, existem desenvolvedores brasileiros de SL e a quantidade deles vêm aumentando recentemente mas navegando por sites especializados como o ohloh.net ou o sf.net é possível ver que ainda falta muito pra gente ser notado no meio das comunidades de SL.

  • 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.