Categoria: Livro

  • É mais fácil pedir desculpas do que permissão

    Diferente do que escrevi no post Dicas para um bom programa em Python, onde eu dou dicas de como proceder para ter um programa Python melhor, desta vez vou falar sobre um estilo que prefiro. Não quero dizer que estou certo ou errado, apenas que prefiro assim.

    It’s easier to ask forgiveness than it is to get permission

    Grace Hopper

    Recentemente, dentro do tempo que me sobrava, comecei a desenvolver uma biblioteca pra fazer requisições HTTP para uma API REST. Essa biblioteca seria usada para criar testes automatizados do projeto que iremos começar a desenvolver aqui na empresa.

    Essa biblioteca faria basicamente o mesmo que a httplib e httplib2 do Python mas com algumas conveniências: (de)serialização de JSON/XML, conteúdo calculado no momento da request (ex. assinatura da requisição), e uma classe “TestCase-like” com funções que auxiliassem no desenvolvimento de testes.

    Eu tinha só algumas idéias do que essa biblioteca faria e quase nada de código quando vi o lançamento do Bolacha, desenvolvido pelo Gabriel Falcão, no Planeta Globo.com. Guardei o link pra conferir depois pois poderia ser útil para o que eu queria fazer.

    Ontem eu tive um tempo para analisar e vi que ele não só seria útil como já fazia a parte mais essencial do que eu precisava (requisições GET/POST/PUT/DELETE/…).

    Como o projeto esta hospedado no github.com tratei logo de fazer um fork para criar as outras funcionalidades que eu precisava. Código legal, código simples, código bem feito, mas… quando encontrei os primeiros…

    def request(self, url, method, body=None, headers=None):
      if not isinstance(url, str):
        raise TypeError(f'Bolacha.request, parameter url must be a string. Got {url}')
    
      if not isinstance(method, str):
        raise TypeError(f'Bolacha.request, parameter method must be a string. Got {method}')
    
      if method not in HTTP_METHODS:
        raise ValueError(f'Bolacha.request, parameter method must be a valid HTTP method. Got {method}. {RFC_LOCATION}')
      
      # ...continua

    … notei que o estilo do Gabriel divergia do meu. Nada errado com isso. Tanto que, mesmo assim, continuarei a usar e melhorar o Bolacha mantendo (dentro do possível) o mesmo estilo original do autor para que ele possa aceitar minhas contribuições.

    O que não gosto desse estilo é que, com ele, sempre estamos pedindo permissão, ou seja, verificando de antemão alguma informação no lugar de usá-la imediatamente e, só em caso de erro, considerá-las inválida. Nesse caso estamos adicionando um overhead desnecessário (muito pequeno neste exemplo) até mesmo para casos de uso correto do método.

    Outro problema que temos nesse estilo reside no fato de que estamos usando o mecanismo de herança da linguagem como um sistema de criação de interface para o objeto. Se eu quiser passar um objeto que se comporta exatamente como uma string mas que não seja uma classe derivada de str para o método .request() acima eu não vou poder.

    Eu removeria todas as verificações de isinstance() e deixaria o código assim:

    def request(self, url, method, body=None, headers=None):
      if method not in HTTP_METHODS:
        raise TypeError(f'Bolacha.request, parameter method must be a valid HTTP method. Got {method}. {RFC_LOCATION}')
      # ... continua

    Mais adiante nesse código vemos o uso de uma função chamada is_file() que é implementada da seguinte forma:

    def is_file(obj):
      return hasattr(obj, 'read') and callable(obj.read)

    Mais uma vez, nada de errado. Mas também não é muito o meu estilo. No meu estilo essa função sequer existiria porque, mais adiante, quando fosse necessário usar obj que, no código em questão, pode ser uma string ou um file object, eu faria algo assim:

    try:
      lines.extend(encode_file(obj))
    except AttributeError:
      lines.extend(['...'])

    Mais uma vez eu quero deixar claro que é só uma questão de diferença de estilo e que eu usei o código do Bolacha somente para ilustrar essa diferença. Dentro do estilo do Gabriel o código está perfeito (tá, não existe código perfeito, mas o dele tá muito bom).

    Como leitura complementar sobre essas diferenças eu recomendo o artigo isinstance() considered harmful, Duck Typing, Permission and Forgiveness e PEP-3119 – Introducing Abstract Base Classes (funcionalidade de suporte ao estilo usado no Bolacha).

    Por último, ao meu estilo, gostaria de pedir desculpas ao Gabriel Falcão por ter usado o código do Bolacha para ilustrar esse artigo sem permissão. 🙂

  • Dicas para um bom programa em Python

    Dicas para um bom programa em Python

    Oi pessoal, desta vez eu vou pular as ‘desculpas’ por ter demorado tanto para postar aqui no blog e vamos direto ao assunto.

    Recentemente eu tenho trabalhado bastante com Python (dã!) desenvolvendo projetos de diversos tipos e resolvi escrever aqui sobre algumas coisas que pratico enquanto desenvolvo.

    Esse artigo é uma espécie resumo com boas práticas de programação Python que utilizo no meu dia-a-dia.

    Código mais robusto

    Deu certo ou errado?

    O que você faz quando acontece algo errado na execução do seu método? O que você responde à requisição que lhe foi feita?

    Eu tenho visto em muito código por aí os desenvolvedores retornando valores sentinela (None, null, 0, -1, etc.) para avisar que algo incorreto aconteceu na execução do método.

    def f(arg):
       if not arg:
          return None
       return ["resultado", "de", "um", "processamento"]

    Algumas linguagens de programação não possuem estruturas de tratamento de exceção e, neste caso, o uso de sentinelas é válido. Mas quando a linguagem de programação te disponibiliza essa funcionalidade é bom usá-la.

    def f(arg):
       if not arg:
          raise ValueError("Argumento Invalido")
       return ["resultado", "de", "um", "processamento"]

    Deixem as exceções fluirem.

    Isso mesmo. A menos que você saiba exatamente o que você deve fazer quando uma exceção aparece deixe-a exceção “subir”. Pode ser que “lá em cima” alguém saiba cuidar dela adequadamente.

    Quando não fazemos isso estamos ocultando informação importante para os usuários do nosso código (sejam eles usuários, outros desenvolvedores ou nós mesmos).

    def f():
       try:
          return conecta()
       except ExcecaoQueDeveriaSerErro:
          return None

    Quando eu implemento esse tipo de método/função eu faço assim (na verdade eu não implementaria f() e chamaria conecta()):

    def f():
       return conecta()

    O que seu método/função retorna?

    Código que eu encontrei recentemente:

    def get_fulanos():
       q = Q("select * from patuleia where alcunha like 'fulano%'")
       ret = [str(fulano['nome']) for fulano in q]
       if len(ret) == 1:
          return ret[0]
       return ret

    Perceberam o que está errado? O seu método retorna uma lista de Fulanos ou retorna Fulano?

    Isso está conceitualmente errado e pode fazer você perder horas preciosas do seu dia tentando achar um bug causado por esse tipo de código.

    Aconteceu comigo. Note que str() implementa uma interface de sequence da mesma forma que list(). Então o erro passa silenciosamente no caso abaixo:

    old_fulanos = ["Ze Ruela", "Ze Mane"]
    old_fulanos.extend(get_fulanos())
    print(old_fulanos)

    Rodando esse código você vai obter ['Ze Ruela', 'Ze Mane', 'q', 'u', 'a', 'c', 'k'] sendo que, em mais de 90% dos casos, o que você gostaria de ter seria: ['Ze Ruela', 'Ze Mane', 'quack'].

    “Nada” é diferente de “alguma coisa”.

    Essa dica é só uma complementação da primeira e da segunda dica.

    Quando o seu método/função retorna uma collection (seqüência, conjunto, hash, etc) vazia você deve retorná-la vazia e não um valor sentinela (como None). Isso facilita a vida de quem vai usar o seu método/função:

    def vazio():
       return []
    
    for elemento in vazio():
       pass #... faz algo se o conjunto contiver dados ...

    Se você retorna um valor sentinela:

    def vazio():
       return None
    
    elementos = vazio()
    if elementos:
       for elemento in elementos:
          pass # ...

    Notou que tivemos que criar uma variável com o resultado da operação (para não precisar chamá-la duas vezes) e tratar a sentinela com um “if“? Se eu esqueço de tratar a sentinela meu programa vai quebrar.

    Lembre-se sempre que uma collection vazia tem valor booleano “False“.

    Todo ‘elif‘ tem um irmão ‘else‘.

    Sempre que você precisar usar uma construção if/elif coloque uma cláusula ‘else‘.

    Além de usar a cláusula ‘else‘ eu geralmente faço com que ela gere uma exceção. Desta forma eu sou obrigado a trabalhar todas as possibilidades nos ‘if/elif‘ evitando ocultar uma situação que pode ser inválida.

    class InvalidCommand(Exception):
       pass
    
    def minihelp(comando):
       if comando == "print":
          return ("Imprime dados na tela. "
                  "Deixará de ser comando "
                  "no Python 3.0")
       elif comando == "assert":
          return ("Certifica se uma condição é "
                  "verdadeira e gera uma excessão "
                  "em caso contrário")
       elif comando == "...":
          pass # ...
       else:
          raise InvalidCommand(f"Comando {comando} inválido.")

    Eu gosto dessa prática mas isso não significa que você deva seguí-la sempre. Existem situações onde ter um “valor default” é necessário e nestes casos o uso do else sem levantar exceção se faz necessário.

    if comando == "if":
       print("Vai usar elif?")
    elif comando == "elif":
       print("Muito bem. Agora falta o else")
    else:
       print("Pronto. Agora está bom.")

    “Pythonismos”

    Use mais atributos públicos do que atributos protegidos (“_“).

    Programadores acostumados com Java utilizam muito as cláusulas ‘private‘ e ‘protected‘ para encapsular os atributos de um objeto para logo depois implementarem os getters e setters para acessar esses atributos.

    Essa prática é aconselhada em Java porque em algum momento do futuro você, talvez, precise validar esses dados ou retornar valores calculados. Nestes casos os programadores apenas implementam essa lógica nos métodos que acessam o atributo privado.

    Mas em Python isso não é necessário. Em Python você pode transformar seu atributo público em uma “property” que não muda a forma de se acessar o atributo e permite o acrescimo de lógica ao acesso do mesmo.

    Evite usar “__“.

    Por convenção, em Python, todo método ou atributo iniciado com um “_” é considerado privado (equivalente ao protected em Java) e não deve ser acessado de fora da classe mesmo sendo possível fazê-lo.

    Dito isso parece meio óbvio que não precisamos usar “__” para dificultar ainda mais o acesso à esse atributo/método. Além disso o uso do “__” traz alguns incoveninentes para quem quer derivar a sua classe e acessar este método/atributo já que o Python o renomeia acrescentando o nome da classe ao seu nome (__attr vira _Classe__attr).

    Não sobrescreva builtins.

    Python disponibiliza várias funções e classes builtins que facilitam muito o uso da linguagem e economizam digitação. Mas esses builtins tem nomes muito “comuns” e frequentemente a gente usa os nomes dos builtins como nomes de identificadores. Eu mesmo vivo (vivia) fazendo isso.

    O problema é que em certos momentos alguns problemas podem acontecer quando você tenta chamar um buitin que já não é mais um builtin. Na maioria das vezes o problema “explode” logo e você rapidamente conserta mas em alguns casos você pode perder muitas horas tentando achá-lo.

    Algumas pessoas usam um “_” no fim do nome do identificador (ex. “id” vira “id_”) mas eu acho isso um pouco feio então uso só quando não encontro uma alternativa melhor.

    Vou colocar aqui uma tabela de equivalências que eu costumo usar para substituir o nome dos builtins mais comumente sobrescritos:

    • id – ident, key
    • type – kind, format
    • object – obj
    • list – plural (lista de element vira elements)
    • file – fd, file_handler
    • dict – dic, hashmap
    • str – text, msg

    Análise estática economiza seu tempo.

    Eu uso o pylint, mas conheço algumas pessoas que preferem o pyflakes ou o PyChecker.

    UPDATE (2023-08-08): utilizo o utilitário ruff com muito sucesso nos meus projetos mais novos. O ruff agrega todos os utilitários acima e mais vários outros.

    A dica é essa: usar um programinha de análise estática como esses pode diminuir consideravelmente aqueles errinhos chatos de sintaxe, ou de digitação. Pode limpar os ‘import’ desnecessários do seu software, etc, etc.

    É lógico que esse tipo de ferramenta não substitui uma boa política de testes mas é um bom complemento para ela.

    Challenge yourself

    Máximo de 3 níveis de indentação. (ou 4 se estiver dentro de uma classe)

    Ao se esforçar para que seu código não fique muito aninhado você está trabalhando melhor a implementação dos seus métodos e funções. Nem sempre é possível (ou aconselhável) restringir tanto o nível de identação do seu código mas muitas vezes isso melhora a sua implementação.

    Máximo de 2 indireções.

    Recebeu um objeto como parâmetro? Chame apenas métodos dele e evite ao máximo chamar métodos do retorno desses objetos:

    def f(obj):
        obj.metodo() # legal!
        obj.metodo().outro_metodo() # ruim!

    Quando você chama um método pra um objeto retornado por outro método você está aumentando o acoplamento entre as classes envolvidas impedindo que uma delas seja substituída (ou reimplementada) ‘impunemente’.

    Essa regrinha é uma das regrinhas da Lei de Demeter.

    Máximo de 0 ‘if/elif/else‘s.

    Polimorfismo é isso. No mundo OO ideal, perfeito e utópico praticamente não precisaríamos do comando “if” e usaríamos somente polimorfismo. Mas… como não conseguimos isso tão facilmente* devemos, ao menos, usar o “if” com moderação.

    Conclusão

    Esta é uma lista incompleta de dicas para programadores Python. Se futuramente eu lembrar ou aprender algo novo eu volto aqui para falar sobre o assunto.

    Alguns desenvolvedores podem não concordar com as dicas. Neste caso eles podem enriquecer ainda mais esse texto argumentando sobre o as suas restrições no espaço para comentários.

    Se você tiver alguma dica para compartilhar com a gente coloque nos comentários. Se ela for boa mesmo eu coloco ela no corpo principal do blog.

    * eu mesmo só consegui fazer uma aplicação OO funcional sem usar um único if. Era uma implementação do joguinho de adivinhação de animais (aquele que pergunta “Vive na água? (s/n)”) em Smalltalk.

    Update: pequena correção sugerida pelo Francisco nos comentários: s/Classe/_Classe/.

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

  • 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

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

  • Invasão bárbara. Como lidar?

    Desde muito tempo tenho participado de fórums e listas de discussões. A grande maioria delas trata de assuntos relacionados à informática mas também de listas com assuntos mais ‘genéricos’.

    Já a algum tempo, com a popularização do acesso à Internet, venho presenciando uma invasão bárbara nos meios de comunicação onde antes costumava imperar as regras de etiqueta (tratada pelos internéticos ‘da antiga’ por netiqueta).

    Quando algum desses bárbaros são inquiridos a se portarem de maneira adequada eles reagem nos tachando de mal-educados, reacionários e puristas da Internet. Eles nos adjetivam dessa maneira porque eles são os mal-educados e porque geralmente acham que qualquer novidade tecnológica que é boa pra eles necessariamente tem que ser boa para todos os outros participantes das listas.

    Alguns casos que saltam mais aos olhos serão enumerados nesse artigo.

    Letra maiúscula serve pra GRITAR!

    Aos bárbaros que não conhecem nenhuma regra de netiqueta ou que não sabem que é possível desligar aquela luzinha do teclado onde está escrito “CAPS LOCK” preciso dizer que, por convenção, escrever em letras maiúsculas (caixa-alta) na Internet é exatamente o mesmo que gritar no ouvido do destinatário da mensagem.

    É muito comum encontrarmos e-mails inteiros escritos em letras maiúsculas. Acho que esse tipo de e-mails só seria válido em listas de discussão que falem sobre letras de música de Trash Metal.

    Quando expliquei isso para um dos bárbaros apontando para ele uma RFC (Request for Comments) que define regras de Netiqueta dizendo que os protocolos da Internet são especificados através desse tipo de documento o bárbaro me chamou de reacionário e afirmou que tal RFC ‘havia sido escrita a mais de dez anos atrás’. É quase como se eu falasse que quem navega na Internet é reacionário porque a RFC que define o protocolo HTTP/1.0 é da mesma época.

    Vamos falar em português?

    Vamos! Mas só em listas, fórums, comunidades do orkut, etc onde o idioma padrão é o português. O brasileiro fica todo orgulhoso da ‘invasão brasileira ao orkut’ e adora mostrar mais essa ‘conquista da amarelinha’ escrevendo em português até em comunidades de “Practice your English”. Parabéns! Nós deveríamos nos sentir orgulhosos por sermos tão mal-comportados bárbaros.

    Já não bastasse os bárbaros escreverem em português nesses fórums, o português usado é de um nível tão baixo que chega a doer os olhos de quem lê. Não precisamos ser o ‘professor Pasquale’. Mas quem consegue ler esse tipo de coisa?

    ‘OI MEU NOME E OSVALDO E ESTOU COMESSANDO AGORA A PROGRAMA EM COMPUTADORES E ESTOU AXANDO TUDO MUUUUUUITO LEGAL E UM AMIGO MEU ME DISSE QUE PROGRAMAR EM PYTHON E SUPERLEGAL ENTAO REZOLVI ESPERIMENTA NE? RSRSRSRSRSRSRSRS E TIPOWWWW… GOSTARIA DE SABER SE SERIA POCIVEL VCS ME AJUDA A FAZER UM PROGRAMA DE CONTROLE DE UZINA NUCLEAR?????????????????????’

    Adoraria que o exemplo acima fosse uma extrapolação do que tenho visto. Mas posso afirmar com absoluta segurança que já vi coisas muito piores. Como poderíamos fazer para explicar para os bárbaros que e-mail não é chat e que até mesmo em chat escrever de maneira totalmente ‘sem-nossaum’ não é uma coisa legal?

    A minha irmã é uma das que escreve desse jeito. Eu já disse pra ela que pra conversar comigo tem que escrever certo. Ela estudou, tem um grau de instrução bom, sempre esteve rodeada de livros e leu vários deles. Quando começou a escrever ‘certo’ comigo fiquei impressionado com a quantidade de erros ortográficos no que ela escrevia. Esse tipo de linguajar ‘internético’ deseduca as pessoas.

    Erros de ortografia, desconhecimento total de uso de pontuação (faltam vírgulas e sobram interrogações e exclamações), erros gramaticais, vocabulário paupérrimo, gírias ‘internéticas’, falta de parágrafos e uma total ausência de ordem na construção do texto já estão virando uma marca registrada da Internet por causa dessa invasão bárbara. Isso é bonito? É algo que deveria dar orgulho ao brasileiro? Do jeito que a coisa anda aqui no Brasil a gente vai comemorar o ‘exacampeonato'(sic) brasileiro no futebol.

    Informação boa é melhor que visual bom

    Tá, quase toda a totalidade dos clientes de e-mail hoje em dia sabem abrir um e-mail em formato HTML (aqueles todos coloridinhos com os smileys gráficos e onde as respostas ficam escritas em azul) mas isso realmente é necessário? E quem não usa esse tipo de cliente de e-mail? E quem tem necessidades especiais (deficiência visual) e precisa usar um cliente especial de e-mail? E quem ainda acessa a Internet usando Modem e uma linha discada?

    Um e-mail em formato HTML é consideravelmente maior do que um e-mail convencional e esse tamanho maior não adiciona absolutamente nada de informação relevante à discussão. Então estamos desperdiçando recursos computacionais por nada. E os bárbaros, com esse tipo de atitude, ainda desperdiçam recursos computacionais dos destinatários de suas mensagens.

    Quando recriminei um bárbaro por usar esse tipo de e-mail ele me chamou de ‘vovô da Internet’ como se isso fosse alguma forma de ofensa e não um elogio à minha experiência superior à dele.

    Ouvir é melhor do que falar

    Quando escrevemos uma mensagem em um fórum escrevemos ela uma única vez e muitas pessoas irão lê-la, correto? Na Internet a gente lê e ouve muito mais do que escreve e fala. Por isso é importante saber ouvir.

    Quando você instrui uma pessoa que sabe ouvir ela te agradece por tê-la ajudado a se tornar uma pessoa melhor. Quando você instrui um ostrogodo ele se considera afrontado e reage mal.

    Concluindo

    Além desses ítems que descrevi aqui ainda existem outros. Resolvi me limitar aos que ocorrem com maior freqüencia para poupá-los de cenas mais fortes 🙂

    Estou tratando desse assunto porque na lista PythonBrasil, onde sou moderador, geralmente somos tratados como rudes, mal-educados e coisas do tipo quando apontamos alguma coisa errada no comportamento dos participantes da lista.

    A lista é uma ferramenta importante para todos que estão lá. Pedimos ajuda, trocamos experiências, aprendemos e ensinamos. Os bárbaros não invadirão o nosso território para nos matar e pilhar, e para que isso não ocorra expulsamos eles da forma mais polida que conhecemos: fazendo eles nos ouvirem. Ao aceitar a ajuda conseguimos ver que ele não é um bárbaro, é apenas alguém inexperiente.

    Agora deixo a pergunta em aberto para que vocês me ajudem: Existe alguma maneira mais eficiente ou mais adequada para lidar com esse tipo de gente?

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

  • Nem tudo é perfeito

    Recentemente, durante o trabalho de escrever o meu livro sobre Python (não, não está pronto e ainda falta muito), me deparei com uma característica que achei superlegal em Python. Essa característica provêm da idéia de que uma string também é uma seqüência tal como listas ou tuplas. Essa característica permite que eu faça coisas como:

    >>> a = [1,2,3]
    >>> a += "spam"
    >>> a
    [1, 2, 3, 's', 'p', 'a', 'm']
    

    Quando estava jantando com o pessoal da PyConBrasil (que aliás foi muito massa) fui mostrar pra eles essa característica, mas como não lembrava exatamente o exemplo anterior eu demonstrei conforme abaixo:

    >>> a = [1,2,3]
    >>> a = a + "spam"
    

    Qual não foi meu espanto quando o resultado obtido foi um:

    >>> a = [1,2,3]
    >>> a = a + "spam"
    Traceback (most recent call last):
     File "", line 1, in ?
    TypeError: can only concatenate list (not "str") to list
    

    Quando vi isso entendi que o ‘problema’ ocorre porque o operador “+=” é mapeado para o método __iadd__() enquanto que o operador “+ é mapeado para o método __add__”.

    Até aí tudo certo. O problema da tal ‘inconsistência’ é que no caso específico dos objetos de listas (list) o método __iadd__() nada mais é do que um apelido para o método extend().

    Após algumas discussões com outros pythonistas de alto nível não foi possível chegar a nenhuma conclusão sobre se iss é ou não é um erro de design da linguagem.

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

    No post de hoje veremos em 5 lições como você deve proceder para que seu projeto falhe completamente. Invariavelmente, se você não se empenhar na aplicação das dicas fornecidas aqui é bem provável que você não consiga fazer com que seu projeto falhe mas apenas que tenha um resultado medíocre que é o atraso do cronograma. Por isso, estude todos as lições para que você realmente consiga fazer com que seu projeto falhe.

    Esse artigo é antigo e não reflete integralmente a minha opinião. Entretanto ele será mantido aqui por motivos históricos.

    Osvaldo Santana Neto

    Lição 1 – Analise, analise e depois analise

    Isso mesmo. Seu projeto corre o risco de ser um sucesso se você não trabalhar bastante na análise do problema a ser resolvido. Já imaginou se no lugar de analisar você tivesse implementando algo?

    Implementar algo é a pior coisa que você pode fazer para que seu projeto falhe.

    Se o problema é simples e não demanda muita análise utilize a sua criatividade para aumentar o problema e tentando convencer o usuário (cliente) de que este problema que ele não tem é algo que ele deveria ter.

    Lição 2 – Trate o projeto de software da mesma maneira que um engenheiro trata o projeto de uma ponte

    Se você tratar o seu projeto como um projeto de software ele tem uma mínima chance de dar certo e isso é algo intolerável para a nossa missão. Faça diferente. Trate o seu projeto de software da mesma maneira que um engenheiro trata do projeto de uma ponte.

    Para fazer isso com sucesso auto-denomine-se “Engenheiro de Software”, além de pomposo (já que você não tem um diploma de engenharia, não estudou Cálculo I/II/III/IV e não está registrado no CREA) representa melhor o trabalho que você fará no seu projeto. Isso implica que você terá que abandonar o título de “Desenvolvedor” ou “Programador” porque esses dois caras aí são caras que “desenvolvem” e “programam” e isso é algo que não devemos fazer.

    Software como o nome diz é algo “soft” (maleável, leve, suave) se tratarmos ele dessa forma teremos sucesso no projeto e não é isso que a gente quer. Então trate o software como algo “hard” (estático, pesado, duro) e para nos certificarmos de que tudo dará certo (quer dizer, errado) trate ele como algo “hard” e “heavy” (pesado, grande). Para podermos ilustrar a nossa idéia:

    Trate o desenvolvimento de um projeto de software como se fosse o projeto de uma ponte.

    Nada mais estático e pesado do que uma ponte (o caso da ponte da BR-116 é uma excessão à essa regra).

    Engenheiros adoram usar coisas como PMI, Microsoft Project, Primavera, etc. Essas técnicas geram planilhas muito legais com cronogramas e tabelas cheias de informações facilmente geradas em uma planilha eletrônica convencional. Mas uma planilha eletrônica convencional não é reconhecida por PMIs e etc.

    Adote a metodologia mais pesada que você conseguir adotar. Uma dica: RUP. Sugira a aquisição da caríssima Suite Rose para que você possa passar dias (ou meses) desenhando quadradinhos e setinhas. Assim vocês terão vários diagramas sexys para mostrar para o cliente em substituição à código implementado e funcionando. A metodologia RUP também adora documentações que é o assunto da próxima lição.

    Lição 3 – Documente

    Ao gerar documentação você estará dando uma importante contribuição para o insucesso de nosso projeto. Mas quando eu falo de documentação eu não estou falando apenas de um ou outro documento “levemente útil” como um resumo e/ou esboço de um diagrama de classes ou diagrama de ER. Eu estou falando de páginas e mais páginas de especificações, cartões, diagramas UML em sua plenitude (status, use cases, …), planilhas de todos os tipos, manuais e todo o resto que sua imaginação permitir. Lembre-se:

    Enquanto você documenta você não implementa, logo, fracassa.

    A documentação é uma boa técnica para que nosso projeto falhe porque além de você perder tempo fazendo ela no começo do projeto você vai ter que perder esse tempo todo novamente no término do projeto para “atualizar” a documentação (coloquei “atualizar” entre aspas porque o “atualizar” alí significa jogar tudo fora e fazer novamente).

    Uma dica adicional nessa lição é: formato é muito mais importante que informação, portanto, deixe o designer que existe em você aflorar durante a confecção desta documentação.

    Lição 4 – Fale “buzzwordês”

    “O beans das business class precisam passar por um deploy” é uma frase que contribui muito mais que “As classes de negócio da camada model precisam ser entregues” para o insucesso do projeto, portanto, extenda seu buzzwordês. Alguns bons pontos de partida para isso é ir nos sites da IBM e Sun (principalmente a parte Java) e ler tudo que fizer referência à J2EE, e-business, etc. (dê uma olhada especial no produto Websphere da IBM… aquilo é um clássico do buzzwordês).

    Essa lição aparentemente não apresenta nada prático que contribua para o não-andamento do nosso projeto mas acredite ela é fundamental para que nosso projeto fracasse.

    Lição 5 – Adote o hype

    Eu tenho uma paixão especial por essa lição. É a que eu tenho mais prazer em ensinar. A minha definição de hype é: tudo aquilo que não tem nada de inovador e mesmo assim promete resolver todos os tipos de problema. Os hypes são criados por pessoas de marketing e pessoas de marketing raramente sabem desenvolver software, logo, se você ‘comprar’ tudo o que eles te vendem é grande a chance de que nosso projeto fracasse e nossa tarefa se torne um sucesso.

    Em alguns casos (raros) o hype pode até não ser a solução para todos os problemas, mas soluciona muito bem algum tipo muito específico de problema (mesmo que não tenha nada de inovador em sua idéia), portanto, cuidado com casos do tipo “vou usar XML para gravar uma informação estruturada num formato padrão texto” porque é exatamente pra isso que XML serve e nesse caso ele se torna útil (blerg!). Use XML em coisas para as quais ele não foi pensado: linguagem de query, linguagem de programação, arquivos pequenos de configuração, etc.

    Prefira usar o “Enterprise jXML .NET” para fazer o seu trabalho do que usar algo que seja simples e funcional. Coisas como J2EE, EJB, JMS, etc são ricos em hypes, portanto, fique antenado à essas coisas.

    Conclusão

    É isso aí, com o passar do tempo eu vou passando algumas lições do “Curso de Projetos Fracassados” para que você sempre esteja por dentro das boas práticas para o insucesso de seu projeto.