“Ondas” tecnológicas

Já é de conhecimento de todos que trabalho com computação já faz muito tempo. Vi muitas ondas passarem.

Quando comecei com BASIC em máquinas de 8bits vi a primeira onda chegar… eram as linguagens estruturadas. Linguagens “procedurais”… código sem GOTO, etc. Quem programava só em BASIC e não conhecia esse “novo paradigma” (aspas propositais) estava fadado ao fracasso e ao ostracismo. Não mereceriam ser chamados de programadores.

Parti para a luta e fui aprender Pascal, C e/ou Clipper.

Assim que dominei esse “novo paradigma” avistei outra “nova onda”: Programação Orientada a Objetos.

Essa foi uma das primeiras grandes ondas que contaram com apoio de Marketing de grandes empresas. Lembro-me de ler sobre “orientação a objetos” até em jornais de bairro (hipérbole detectada!). E mais uma vez fui convencido de que se não dominasse esse “novo paradigma” eu estaria fadado ao esquecimento.

Então comecei a estudar o assunto e no meu entendimento inicial (e duradouro) uma “classe” nada mais era do que um “struct” (ou RECORD) com esteróides. Ainda existem registros da minha primeira incursão nesse novo mundo. Eu só fui entender melhor OOP recentemente.

Outra onda que “bombou” mais ou menos na mesma época era a dos bancos de dados relacionais (SQL e afins). Mas eu não tinha muito contato com esse mundo que era restrito às “elite$”.

E com OOP e SQL essas empresas de marketing que, eventualmente, produziam software começaram a ganhar rios de dinheiro vendendo “gelo para esquimó”.

A tecnologia dos computadores surgiu para empresários em mensagens como: “Se sua empresa não usar OOP ou SQL você (perderá dinheiro|será devorado pela concorrência|será feio e bobo).” — (IBM|Gartner|Oracle)

Os empresários eram completamente ignorantes sobre esses assuntos e, num ato de fé, acreditavam em tudo o que as “IBMs” diziam. Afinal elas ficaram grandes e ricas por lidar com tecnologia, certo? Conseguem detectar a falha primordial nesse raciocínio?

Esse tipo de mensagem juntamente com a outra que dizia: “ninguém é demitido por ter escolhido IBM” fez muito bem para o lucro dessas empresas.

Naquela época isso fazia sentido, afinal, os computadores não faziam parte da vida de todo mundo. Tecnologia e mágica eram sinônimos. Mas hoje isso não deveria mais ser assim. A fábrica de “hypes” continua funcionando e os empresários e profissionais da área continuam investindo em tecnologias “da moda” apenas por estarem na moda.

Outras “ondas” movimentaram e ainda movimentam o mercado e com certeza não lembrei de todas: OpenSource, Java (J2EE), XML, NoSQL, Cloud, metodologias de desenvolvimento (ágeis ou não), Big Data, Internet of Things, Frontend/Backend engineering, etc.

Para cada uma delas temos defensores (não é uma onda! é realidade! olha só isso aqui!) e detratores (isso é hype! isso não funciona!). Ambos estão certos e errados.

Meus amigos devem estar pensando: “Mas ele é o cara que mais compra esses hypes! Andava com uma camiseta ‘você ainda usa banco de dados?’!”.

Eu, de fato, acompanho todas essas ondas. Cada uma delas acrescenta algo na minha caixa de ferramentas. Sempre que vejo uma delas chegando já vou logo dando uma chance pra elas se provarem úteis. Mas isso não significa que vou adotá-las em tudo o que farei e que as coisas antigas são lixo.

É o velho clichê: existem ferramentas certas para resolver cada tipo de problema.

Resolvi escrever isso pra que vocês possam refletir sobre a adoção racional de tecnologias. Usar critérios técnicos para a escolha e não ficar pegando jacaré em qualquer onda que aparece.

Outra coisa importante é não parecer bobo falando que você faz “Big Data” pra um cara que já processava toneladas de dados antes mesmo de terem cunhado essa expressão. Ou falar que usa NoSQL pra um cara que já usava Caché (kind of OODBMS), LDAP (hierárquico), ou Isis (schemaless).

Como vivi todas essas ondas eu saco logo que esses caras são mais “gogó” do que outra coisa.

Mantenham o foco em criar coisas boas que resolvam problemas importantes e escolham tecnologia usando critérios técnicos.

Ser proficiente numa linguagem é um critério muito importante mas ele deve ser considerado em conjunto com outros critérios (robustes, disponibilidade de recursos, etc).

Dia desses vi um anúncio procurando programador Clipper e pensei: esse contratante deve ter um excelente software. Deve ser um software tão bom e deve resolver problemas tão importantes que ele resistiu à várias ondas e não virou areia.

Code Review e a Teoria das Janelas Quebradas

Na empresa onde trabalho temos o (bom) hábito de fazer Code Review no código dos projetos que desenvolvemos. A prática não é obrigatória mas todos os desenvolvedores gostam de ter seu código revisado.

Eu adoro revisar código alheio tanto quanto gosto de ver meu código revisado e, por isso, me esforço para dar pitaco até em quase todos os projetos da empresa. Até em projetos de outras equipes.

Eventualmente eu entro em debates para que os desenvolvedores renomeiem variáveis ou até mesmo que coloquem ou retirem espaços em branco que violam o Coding Style da empresa. Como usamos Python adotamos a PEP-8 com apenas uma ressalva relativa ao número de colunas por linha que acaba estabelecida apenas pelo bom senso de cada programador.

E eu sou “chato” com isso. Eu realmente implico com qualquer desvio coisa que não me pareça certa. Sejam elas críticas ou triviais recebem a mesma atenção.

Existe uma teoria que afirma que as janelas quebradas de edifícios em uma região da cidade tem relação direta com a criminalidade nesta mesma região.

Eu acredito nessa teoria e, por isso, sou extremamente exigente nas minhas revisões. Faço isso porque acredito que um mero relaxo numa linha em branco dentro do arquivo pode evoluir para um desenho ruim de um módulo inteiro da aplicação.

Ok, admito, isso pode parecer exagero mas… e se não for? E se a teoria das janelas quebradas se aplica também no contexto do código fonte de uma aplicação?

Esse tipo de cuidado é ainda mais importante quando trabalhamos com linguagens de programação com tipagens dinâmica ou fraca pois certas convenções de nomenclatura podem dizer muito sobre os tipos envolvidos em uma operação. Exemplo?

Uma função chamada get_user() retorna que tipo de objeto? Eu presumo que seja uma instância de um objeto representando um usuário (ex. User). Mas só consigo presumir isso pelo nome da função (ou me dando ao trabalho de ler e entender a sua implementação).

E a função get_users(), o que retorna? Presumo que seja uma coleção (collection) de objetos representando usuários, certo? Se o desenvolvedor descuidar dessas e de outras convenções o trabalho ficará bem mais complicado para os outros membros da equipe.

Certa vez eu encontrei um código que fazia algo parecido com isso:

user = self._get_user_from_credentials(request)

Conseguem perceber o que está errado? O método diz que retorna um usuário a partir de suas credenciais (ex. username, senha, …) e enviamos para ele um objeto do tipo Request? Pedi para corrigir o problema de uma das duas formas:

  1. passando as credenciais do usuário para o método ou;
  2. renomeando o método.

Optaram por renomear o método e o código ficou assim:

user = self._get_user_from_request(request)

Note que é um método protegido (em Python o prefixo ‘_’ é usado para informar que o método em questão não deve ser chamado externamente) e, por isso, não seria um problema muito grave manter o nome antigo. Mas mantendo como estava deixariamos uma janela quebrada em nosso código.

Remote

Resenha de livro: Remote

Desde o começo do ano eu estou trabalhando em Curitiba para uma empresa de São Paulo. É a primeira vez que estou trabalhando realmente de forma remota.

Por problemas de falta de espaço em casa eu trabalho em um espaço de coworking com mais 3 desenvolvedores da mesma empresa. É quase como se fosse uma filial da empresa em Curitiba com a diferença de que a opção de ficar em casa também é aceita.

Mas não está muito fácil. A cultura do trabalho remoto é muito nova na empresa e ela está sendo criada junto com outras medidas de melhoria: adoção de metodologias ágeis, boas práticas no desenvolvimento de projetos, migração da mentalidade “serviço” para uma mentalidade “produto”, entre outras.

O fato é que durante esse ano a interação e a produtividade da equipe não foi a melhor possível e resolvi investigar a situação para tentar encontrar os problemas e sugerir mudanças.

Em conversas preliminares e por experiência própria (quando trabalhei na Conectiva) pude perceber que para uma empresa funcionar bem com equipes remotas ela precisa funcionar “remotamente” mesmo entre as pessoas que estão debaixo do mesmo teto.

Na Conectiva, por exemplo, boa parte da comunicação da empresa se dava via e-mail (individuais ou em listas de discussão) e salas de chat (IRC interno). As pessoas se esforçavam para usar bem esses canais ao tratar de quase todos assuntos. Existiam canais e listas até para “piadas de corredor”. Adotar o modelo de trabalho remoto, na Conectiva, seria moleza.

Esse raciocínio foi ratificado posteriormente por um amigo que trabalha na Canonical. Onde todos trabalham remotamente.

Na empresa onde eu estou isso não acontece. Ainda existe muito “apego” à conversa olho-no-olho e à reuniões presenciais e isso, certamente, é o que está causando dificuldades na nossa equipe.

Tentando entender mais sobre esse assunto eu adquiri o livro Remote escrito pelos fundadores da 37signals e autores de outros livros muito bacanas: Rework e Getting Real (digital gratuíto ou impresso).

Remote

RemoteA 37signals é uma empresa que tem um escritório em Chicago onde a maior parte da equipe nunca aparece. Todos podem trabalhar remotamente por lá. Por conta disso eles resolveram abordar esse assunto que ainda gera muita desconfiança dentro das empresas.

O livro é bacana e tem um bom apanhado sobre todos os aspectos do trabalho remoto. Tudo é tratado de forma bastante aberta, franca e honesta. Eles mostram as vantagens mas também mostram as desvantagens dessa modalidade de trabalho e dão algumas dicas práticas para amenizar (mas não solucionar) essas desvantagens.

Ele também desmistifica alguns assuntos tanto para empregadores quanto para empregados. Bobagens como “trabalhadores remotos podem ganhar menos” ou “trabalhar remoto é moleza porque posso trabalhar menos” são destruídas pelo texto.

Os livros da 37signals sempre tem muitos capítulos curtos e sucintos com ilustrações interessantes separando os assuntos. Esse não é diferente. São 38 capítulos (com 1 ou duas páginas apenas) divididos em 5 partes principais:

  1. Beware the Dragons – porque o trabalho remoto pode ser bom para todos? Como a tecnologia viabilizou o trabalho remoto para diversos tipos de profissão? Como iniciar a implementação do trabalho remoto?
  2. Hiring and Keeping the Best – como contratar profissionais para trabalhar nessa modalidade de trabalho? Como o trabalho remoto se torna um ótimo atrativo para contratar os melhores?
  3. Managing Remote Workers – como gerenciar equipes remotas? como lidar com cada integrante da equipe individualmente?
  4. Life as a Remote Worker – como trabalhar remotamente? Como organizar melhor o tempo? Como construir o ambiente de trabalho?
  5. Conclusion – “os finalmentes” :D

Adquiri a versão digital e li no Kindle. Foi bem legal e a versão digital tá bem diagramada.

O plano agora é enviar uma cópia para os chefes. Porque fazer isso dar certo depende de um esforço de todos.

Dono

Resenha de Livro: Dono

Quando trabalhava com Linux na Conectiva tive contato com um cara chamado Marcelo Toledo. Ele era da área de tecnologia e usava Linux em suas empreitadas. Por alguns anos a gente perdeu o contato e ele seguiu com seus projetos e eu com os meus.

No ano passado eu fui convidado para trabalhar como CTO da Kanui, uma empresa da Rocket Internet, e acabei “esbarrando” com o Marcelo nos corredores do prédio onde a maioria das empresas do grupo ficam sediadas.

Eu não o reconheci imediatamente mas ele me reconheceu e me cumprimentou. Ele era Founder da Payleven (também do grupo Rocket) e fazia questão de, sempre que possível, bater um papo sobre tecnologia comigo.

O Marcelo fundou e/ou foi CTO de algumas startups de sucesso. A mais conhecida delas certamente foi a Vex (que fornecia hotspots WiFi em locais públicos).

Como eu já trafegava no meio de startups, tecnologia e de assuntos relacionados a empreendedorismo continuei acompanhando o trabalho dele mesmo depois que saí da Kanui.

Foi quando soube que ele estava preparando um novo livro que contaria tudo o que ele sabe sobre a criação de startups no Brasil.

Empreendedor e Dono

DonoTerminei de ler o livro “Dono” ontem de noite e gostei bastante do conteúdo. Ele é ideal para empreendedores que planejam se lançar na aventura de construir uma startup usando metodologias conhecidas por Business Model Generation (também em versão traduzida) e Lean Startup (que também foi traduzido).

Também dá várias dicas práticas sobre assuntos relacionados à Venture Capital, investidores, rounds de investimentos, etc.

O livro é bastante completo e prático e recomendo ele como primeiro livro para compreender esse universo. Eventualmente será necessário buscar informações complementares em livros que ele também recomenda.

O livro tem prefácio muito legal do Nizan Guanaes e um depoimento do João Doria Jr. e é dividido em três partes principais: Aprender, Executar e Crescer.

Na primeira parte ele conta um pouco da história dele como empreendedor, define o que é uma startup, fala sobre o valor de uma idéia (muito pouco) e de uma boa execução. Também dá uma pincelada em assuntos que você certamente precisará dominar se decidir embarcar nessa aventura.

Na parte de execução ele nos convida para por a mão na massa e desenvolver a nossa startup desde o business model (modelo de negócio) até a criação da empresa (incluindo aí as etapas de Desenvolvimento de Cliente, Validação de Cliente, Ajuste Produto/Mercado e Produto Mínimo Viável. Todos conceitos do modelo Lean Startup.

Passada essa fase de execução você provavelmente estará pronto para desenvolver o seu negócio e faze-lo crescer. E mais um conjunto grande de aprendizado precisa estar garantido no seu arsenal: aquisição de clientes, métricas, investimentos, fluxo de caixa, EBITDAs e P&Ls… Todas essas coisas que parecem muito assustadoras que são desmistificadas no livro com uma linguagem simples e direta ao ponto.

O autor também disponibiliza muito material de apoio no site do livro.

Minha opinião sobre esse modelo de startup

Recentemente eu tenho acompanhado o desenvolvimento de startups que preferem uma abordagem mais conhecida como side-project ou bootstrap. E desde que comecei a prestar atenção em startups que nasceram com esse mindset pude notar que o crescimento delas é geralmente menor que o de uma empresa que recebe investimentos mas é um crescimento constante e sustentável no longo prazo.

Já não tenho mais tanta “fé” no universo de startups inspirada no modelo “Vale do Silício” onde se fala muito em anjos, aceleradoras, pitches, VCs, seed, rounds, e outros “blablablás”.

Esse universo é tão grande e cheio de coisas para nos preocuparmos que fatalmente deixamos de focar na coisa que mais importa: o nosso negócio.

No modelo side-project/bootstrap você (e seus sócios) ficam responsáveis por viabilizar a empresa e levá-la adiante até o seu crescimento. Quando vocês optarem por aceitar a ajuda de um investidor será apenas para melhorar ou acelerar aquilo que já daria certo de qualquer forma.

Além disso aqui no Brasil tem muito “acelerador”, “anjo” e “investidor” que prefere explorar a boa-fé do empreendedor à ajudá-lo a crescer e melhorar seu negócio.

Por último é importante deixar claro que existem certos tipos de startups que são  inviáveis ou extremamente difíceis de se levantar sem o aporte de investimento externo.

Coisas que você talvez não saiba sobre Linux/Unix/OS X

Já faz bastante tempo que trabalho com Linux e outros unices ao lado de gente muito foda. Ao longo desse período fui aprendendo algumas dicas e macetes que, quando uso na frente de alguns amigos, deixam eles espantados.

São coisas simples que talvez vocês já conheçam mas que vou colocar aqui como referência para as “futuras gerações” :D

Matando um processo que não quer ser interrompido

Você executa um comando na linha de comando e ele fica travado. Você dá ^C (CTRL-C) e ele não morre? Tente ^\ (CTRL-\).

Complementação enviada pelo meu amigo Rudá Moura: ^C envia um SIGINT, ^\ envia um SIGQUIT, o kill (sem argumentos) envia um SIGTERM e o kill -9 (que deve ser usado somente se você já tentou o SIGTERM) envia um SIGKILL que é o único sinal não interceptável pelo processo.

Sessão SSH travou? Chame o ~

Você deu ssh para um servidor e por algum motivo a sessão ficou pendurada?

Tecla “<ENTER>~.” e a sessão será encerrada imediatamente. Lembre-se que se vc usa um teclado com acentuação deadkeys você precisarar digitar “<ENTER>~<SPACE>.“.

Esse é o comando-til mais legal mas existem outros:

$ man ssh  # procure por "ESCAPE CHARACTERS"

Arquivos com - no início do nome?

Uma brincadeirinha que a gente fazia com a molecada que chegava pra trabalhar era criar um arquivo chamado “-rf ~” em algum lugar na máquina do cara e desafiar: “apague esse arquivo na linha de comando”.

Tem algumas respostas certas para esse desafio mas rm -rf ~ (CUIDADO COM ISSO!) certamente não é uma delas :D Tentar fazer escape do “-” ou fazer rm "-rf ~" também não vai funcionar. Os comandos vão interpretar esse sinal como uma opção do próprio comando e não como um argumento do tipo nome de arquivo.

Solução?

rm -- "-rf ~"

Quando colocamos o -- informamos pro comando que todos os parâmetros passados a partir daquele ponto são argumentos para o comando e não opções do comando.

O meu amigo Elvis (EPx) e o Fedalto conhecem outra forma que também permite remover esse diretório:

$ rm -rf ./-rf\ ~

Debugando problemas em software alheio

Você tem um software que simplesmente não está funcionando direito e não dá nenhuma mensagem que te ajude a resolver o problema? Esse software não é seu; foi feito em C; você só tem o binário; etc?

Na minha experiência de vida quase sempre esses problemas acontecem por causas “bobas” como um arquivo de configuração que não está no lugar certo ou está com as permissões incorretas, um processo tentando alocar um recurso que já está sendo usado por outro, etc. Mas como saber disso se a única coisa que aparece pra mim é um enigmático “Segmentation Fault”?

# strace [-p PID|software] [-f]

O strace mostra todas as syscalls que um processo está executando no console. Como é muita informação é sempre legal redirecionar essa saída para um arquivo e analisar depois.

Quando o software caiu você abre o arquivo de log e procura (de trás para frente) por mensagens de erro logo antes do programa morrer. Já resolvi dezenas de problemas assim.

Vale lembrar que essa ferramenta deve ser encarada como um tipo de “último recurso” quando outras técnicas de resolução de problemas já não estiverem funcionando mais.

No OSX o utilitário que imita o strace se chama dtruss e o jeito de usar é bem similar.

Pausando o console

Você executou um tail -f arquivo.log mas os logs chegam numa velocidade que te impedem de analisar as mensagens?

Faça um Pause no terminal: ^S (CTRL-S). Para liberar o Pause: ^Q (CTRL-Q).

Alternando entre jobs

Executou um comando e deu ^Z. Executou outro comando e deu ^Z novamente. Ficou com dois jobs parados, certo? (execute o comando jobs para ver os dois processos parados).

Para trazer um deles devolta para o primeiro plano use o comando:

$ %N  # onde N é o número do job

O Aristeu pediu pra lembrar que esse comando é uma espécie de atalho para o comando fg:

$ fg N

E que, fazendo par com o fg tem o comando bg N que “despausa” o processo e coloca ele pra funcionar em segundo plano.

Se você quer executar um processo direto em segundo plano é só colocar um & no fim da linha:

$ find / > lista_de_arquivos.txt &

É o mesmo que fazer ^Z e bg.

Reexecute comandos

Você digitou um comando grande e chato na linha de comando, precisa reexecutar ele mas ele tá lááá atrás no histórico? Não precisa ficar com a setinha pra cima até cansar. É só usar a !:

$ find . -type f | while read i; do mv "$i" "$i.bak"; done  #ok, eu sei que dá pra melhorar isso mas queria uma linha grande, ok? :D
$ ...
$ ...
$ ...
$ # vamos reexecutar o find|while
$ !fin

Buscando no histórico de comandos

O Thiago Santos, o Aristeu e o toti pediram pra eu acrescentar a busca no histórico. Eu acho que muita gente já sabia desta dica e por isso não coloquei na primeira versão desse artigo. Mas… como tem gente que talvez não conheça aí vai.

Eu uso o modo VI no console (próximo tópico) e para fazer buscas no histórico de comandos eu uso os comandos de busca do próprio vi: <ESC>/string_de_busca. Para repetir a busca basta ir acionando a tecla N.

Por padrão a maioria das distribuições Linux (e alguns Unix) usam o modo emacs e para fazer a mesma busca usa-se o comando CTRL+R. Agora é só digitar a string de busca e <ENTER>. Para repetir a busca use o comando CTRL+R novamente.

Modo VI no console

Tive um amigo que dizia que você não pode se considerar um usuário de VI se usa o modo emacs (default) no console.

Para alternar para o modo VI (erroneamente chamado de modo que bipa pelos detratores do VI) é só digitar:

$ set -o vi

Ou acrescentar as linhas abaixo ao teu ~/.inputrc:

set editing-mode vi
set keymap vi

Nesse modo você usa os comandos do VI navegar no histórico, fazer busca dos comandos, etc. Exemplo: para buscar o comando find no histórico você digita <ESC>/find<ENTER> e para procurar as próximas ocorrências é só ir apertando N. Encontrando o comando é só dar <ENTER> para executar o comando ou I para entrar no modo de edição e alterar o conteúdo da linha.

Mas o mais legal desse modo é que você pode chamar a linha de comando no VI a qualquer momento. Vamos supor que você digitou uma mega linha comprida na linha de comando e começou a ficar complicado de edita-la. No modo VI basta você digitar <ESC>vi e o editor VI será carregado com todo o conteúdo da sua linha de comando.

Se você gravar e sair (:wq) a linha será executada. Se você só sair sem gravar a linha será ignorada.

Resetando o terminal

Você estava lá trabalhando na linha de comando e acidentalmente deu um cat num arquivo binário achando que lá só tinha texto. Teu terminal ficou todo zoado com símbolos irreconhecíveis no lugar dos caracteres? É só resetar o terminal:

$ reset

Funciona na imensa maioria das vezes. Mas se não funcionar… aí é só matando esse terminal mesmo :D

Agradecimentos para o toti por ter feito me lembrar dessa dica :D

Último argumento

Essa eu não conhecia e foi passada pelo meu colega Vinicius Assef:

$ git diff path/para/meu/arquivo_que_mudou.py
$ git add !$

O !$ pega o último argumento do último comando digitado no shell.

Para saber mais sobre essa e outras expansões possíveis:

$ man bash  # procure por ^HISTORY EXPANSION

Sabe algum macete que não está aqui?

Eu sei de mais alguns outros vários mas não consegui lembrar pra colocar aqui. Conforme for lembrando vou atualizando esse artigo. E você sabe algum? Mande para blog @ osantana (dot) me.

Personal Python Style Guide

No lugar onde trabalho usamos Github e usamos a funcionalidade de Pull Request para sugerirmos melhoria no código da empresa.

Eu adoro esse sistema porque ensinamos e aprendemos a programar melhor. Mas algumas sugestões eu evito colocar porque elas são baseadas em minhas preferências pessoais e não em fundamentações técnicas.

Essas eu vou colocar aqui e apontar esse post para meus colegas de trabalho (e amigos). Quem gostar pode adotar.

São escolhas e opções de estilo que vão além do que a PEP-8 propõe.

Múltiplos pontos de retorno

Vejo muito código assim:

def f(x):
    if x == "spam":
       do_something()
       do_something_else()

Não tem nada de errado com esse código. Mas eu fico incomodado com o fato de que todo o código dessa função está dentro do bloco do if. Eu prefiro, quando possível, inverter a lógica do if e inserir um ponto de retorno extra na função:

def f(x):
    if x != "spam":
       return
 
    do_something()
    do_something_else()

Tenho amigos programadores que não gostam de inserir pontos de retorno extras na função. Eles tem argumentos bons e fortes para defender o “jeito deles” e eu tenho os meus argumentos para defender o “meu jeito”.

if/elif tem que ter um else

É claro que um bom sistema de objetos com interfaces claras e polimorficas eliminaria toneladas de lógica condicional do seu código. Mas, vamos lá, no mundo real os ifs estão por aí.

Junto com os ifs temos os elifs que podem ser usados (com moderação) para nos ajudar a colocar um pouco de vida ao nosso código.

Mas quando eu vejo isso:

def f(x):
    if x == "spam":
       do_something()
    elif x == "eggs":
       do_something_else()

O meu TOC (Transtorno Obsessivo Compulsivo) “apita” e eu tenho que “consertar” esse código pra algo mais ou menos assim:

def f(x):
    if x == "spam":
       do_something()
    elif x == "eggs":
       do_something_else()
    else:
       return

Já teve casos onde fiz else: pass só pra poder dormir de noite. :)

Deixando a brincadeira de lado, colocar um else em todas as construções que tenham elif é uma prática de programação defensiva. É bastante comum encontrar algo parecido com o código abaixo nos sistemas que desenvolvo:

def f(x):
    if x == "spam":
       do_something()
    elif x == "eggs":
       do_something_else()
    else:
       raise SystemError("Invalid argument")

Esse tipo de código evita que erros passem desapercebidos pois uma exceção será gerada sempre que um argumento incorreto for passado para essa função. Com isso eu posso corrigir o problema ou acrescentar um elif novo para tratar esse novo argumento.

Consistência, retornos e erros

Esse talvez seja um caso mais sério do que apenas uma “questão de estilo” porque afeta a qualidade geral do código se não adotada de forma correta.

Em linguagens dinâmicas não declaramos os tipos dos identificadores e isso traz uma série de benefícios mas também força o programador a seguir uma série de regras para evitar dores de cabeça. Uma delas é a de que as interfaces (métodos ou funções) precisam retornar valores consistentes.

def is_odd(n):
    try:
       return n % 2 == 1
    except TypeError:
       return

O código acima é o de uma função que retorna True se o número passado como parâmetro for ímpar. Se o valor passado como parâmetro não for um número o retorno é None

Essa função tem um problema de estilo: quando um valor incorreto é passado para uma função ela deveria avisar o programador sobre esse erro. Como fazemos isso? Com o sistema de exceção!

Então não tem problema receber um TypeError exception quando passamos uma string para uma função que deveria receber apenas números. O código que está chamando essa função claramente tem um bug que precisa ser corrigido.

O outro problema vai um pouco além da questão estilo. Essa função deveria ter um retorno booleano, ou seja, deveria retornar um valor do conjunto (True, False). Mas isso não está acontecendo. Ela pode retornar None que é um não-valor que não faz parte do conjunto dos booleanos.

E pior: apesar de não fazer parte do conjunto dos booleanos, o None é interpretado como False pelo Python e isso pode fazer com que erros fiquem ocultos por muito tempo em nosso código.

Essa função, para mim, deveria ser implementada assim:

def is_odd(n):
   return n % 2 == 1

Singular para um, plural para muitos

O nome que escolho para os identificadores no meu código refletem (parcialmente) o tipo de dado que eles referenciam.

def is_odd(n):
   return n % 2 == 1

Se a função tem um nome iniciado com is_* ela retornará um valor booleano.

def odds(r):
   return [n for n in range(r) if n % 2]

Se o identificador tem plural no nome (odds) ele vai retornar uma coleção (collection) ou um iterador (iterator).

def next_odd(n):
   return n + (2 if n % 2 else 1)

Se o nome do identificador estiver no singular ele vai retornar um valor único.

class Odds(object):
   def __init__(self):
      self.odds = []
 
   def load_odds(r):
      self.odds = [n for n in range(r) if n % 2]

Quando o identificador tem um verbo “impositivo” no nome ele não retorna nada (eu raramente uso métodos get_* que violam essa regra). O mesmo, neste caso, quando o método faz mudanças inplace no objeto.

Essa regra que diz que métodos que fazem mudanças inplace nos objetos não devem retornar valor é adotada pelo próprio Python, por exemplo, nos casos dos métodos list.sort() ou list.reverse().

To be continued…

Assim que eu me lembrar de outras coisas vou atualizar esse artigo. Se você tem sugestões de estilo que vocês adotam no dia-a-dia escrevam nos comentários.

A Procura da Felicidade

À Procura da Felicidade

Um dos filmes mais bacanas que assisti nos últimos anos foi o “À Procura da Felicidade”, estrelado pelo excelente ator Will Smith e por seu filho Jaden Smith.

O filme conta a história de vida do empresário e investidor Chris Gardner desde quando ele começou a sua jornada rumo ao sucesso e à felicidade. O filme mostra uma parte muito difícil da vida de Chris Gardner quando ele teve que morar nas ruas junto com seu filho.

À Procura da FelicidadeMe interessei pela história e descobri que o filme tinha sido baseado em sua biografia publicada em livro. Foi o primeiro livro em português que li inteiramente em formato digital (adquirido na Kindle Store brasileira).

Então vamos ao livro…

Primeiro que, como já era de se esperar, o livro é bem mais abrangente com relação à vida de Chris Gardner do que o filme. O livro cobre desde a infância na casa de uma tia, quando recebia visitas temporárias de sua mãe (ela passou alguns períodos presa por ter revidado às agressões de seu marido), e vai até quando ele se encontrou pessoalmente com Nelson Mandela.

O livro tem partes bem pesadas como a que mostra que ele foi vítima de estupro durante sua adolescencia. Mostra as dificuldades de se viver como negro, pobre, vítima de um padrasto violento, etc.

A parte narrada no filme é um trecho bem pequeno do livro (menos do que a metade final).

O filme também “inventa” algumas partes que não aparecem no livro: a parte em que ele resolve o Cubo de Rubik e a parte onde ele cita o trecho da constituição norte-americana que fala sobre “a procura pela felicidade” não aparecem explicitamente no livro. Essas partes podem ter sido incluídas no filme com a ajuda do próprio Chris (que trabalhou como consultor durante as filmagens).

O filme também dá uma embaralhada em algumas partes da história: no filme ele ainda tinha máquinas médicas para vender quando já morava na rua. No livro ele já tinha abandonado o negócio de máquinas médicas e já tinha começado como estagiário em uma empresa de investimentos quando foi morar na rua.

Enfim… o livro é mais completo, real e “cru”. O filme é mais poético. Talvez por isso esse é um dos poucos casos onde acho o filme melhor do que o livro. O filme consegue passar melhor as mensagens de superação, força de vontade e determinação.

À Procura da Felicidade

Serie Inteligência

Série Inteligência

Perluigi Piazzi ou, simplesmente, Prof. Pier é um famoso professor de física e pioneiro no uso de computadores na década de 80. Ele foi editor ou autor dos primeiros livros sobre MSX no Brasil (publicados pela editora Aleph especializada em títulos sobre SciFi).

Prof. PierRecentemente eu redescobri (ou seria reencontrei?) o Prof. Pier quando estava lendo alguns artigos “for Dummies” sobre aprendizado e neurociência. Estava lendo sobre esses assuntos porque sempre me interessei por questões relacionadas ao ensino e ao aprendizado, e porque agora sou pai de duas crianças lindas e inteligentes.

No meio das várias abas do meu navegador tinha uma apontada para um site que falava sobre Neuropedagogia. Imaginem a minha surpresa ao ver que o site era mantido pelo Prof. Pier! O mesmo que me ensinou (através de seus livros) a programar computadores. A minha profissão.

O material do site é excelente e dá uma boa noção sobre a Neuropedagogia. Resolvi que eu deveria me aprofundar no assunto e comprei a série inteira que ele escreveu sobre esse assunto.

A série tem 3 livros:

  1. Aprendendo Inteligência – voltado para alunos que queiram entender o funcionamento do cérebro no processo de aprendizado. A abordagem é um pouco mais superficial e direcionada a estudantes.
  2. Estimulando Inteligência – voltado para os pais. Os pais são parte importante do processo de aprendizagem e nesse livro eles encontrarão o conteúdo explicado no Aprendendo Inteligência e a complementação necessária para eles auxiliarem os seus filhos no processo.
  3. Ensinando Inteligência – voltado para profissionais da educação. É o mais completo de todos. Repete algum conteúdo dos dois anteriores com mais profundidade e complementa com informações importantes para profissionais de pedagogia.

Os 3 livros são fartamente ilustrados, a leitura é extremamente agradável e fácil, as referências para outras obras (inclusive de SciFi) é enorme e as dicas são valiosíssimas.

Lá em casa a gente já adotou algumas das práticas sugeridas e é perceptível a diferença. Pretendo levar as sugestões para a escola onde ele estuda. Os livros são tão bacanas que não para na minha estante… todo mundo pede emprestado :D

Um assunto que me interessa, escrito de forma inteligente por uma pessoa que fez parte da minha formação. Imperdível.

A Startup de $100

A Startup de $100 e minha nova vida

Esse post reinaugura a minha sessão de reviews e escolhi o livro “Startup de $100″ do Chris Guillebeau porque foi o livro sobre empreendedorismo que mais gostei de ler recentemente. Gostei dele porque ele fala sobre um tipo de empreendedorismo que eu conhecia pouco e que tem tudo a ver com meu estilo de vida atual.

Tempos atrás, enquanto trabalhava na minha empresa, eu lia e me informava sobre tudo no mundo das Startups e me tornei um “startupeiro”. Startupeiro é aquele cara que sabe sobre todas as novas startups, investimentos, aquisições, IPOs e fala sobre aceleração, anjos, seeds, rounds, etc. Participa de editais de governos, eventos de pitches, etc. Mas… um startupeiro jamais cria um negócio viável de fato porque ele fica distraído com esse monte de coisa e não foca na criação de seu negócio. Fiquei nessa levada por uns 3 anos e notei que minha empresa nunca desenvolveu nada de grande valor. Só andei de lado.

No final de 2011 notei que minha família, que sempre me apoiou, começou a se cansar desse ritmo de vida que eu estava levando: ausente, estressado, sem grana e sem perspectiva de que as coisas melhorariam. Ao mesmo tempo o mercado de trabalho para desenvolvedores estava bombando. Empregos bons, bons salários, falta de mão de obra com minhas qualificações, etc.

Via a minha família no aperto e meus filhos sentindo a ausência do pai. Eu tinha que decidir: insistir com a empresa, manter a empresa como atividade paralela, ou ficar apenas como empregado?

Optei pelo canal intermediário e isso funcionou (mal e porcamente) por quase um ano até eu sofrer uma queda de moto. O acidente fez com que eu começasse a valorizar ainda mais a minha família e a minha saúde. Por conta disso iniciei um plano de desaceleração que incluia: conseguir um bom emprego (check), fechar todos os meus negócios (doing) e terminar meu mandato na APyB (doing). Ficaria apenas com meu emprego e alguns hobbies.

A Startup de $100

Você deve estar pensando: “tá, mas vc decide deixar de empreender e compra um livro sobre empreendedorismo?”.

Foi o acaso que me trouxe esse livro. Eu havia viajado a trabalho e esqueci de colocar alguma coisa para ler em minha bagagem. Na livraria do aeroporto eu vi esse livro em promoção e resolvi comprar para ler. Alguns amigos haviam comentado que o livro era legalzinho então não tinha muito risco de desperdiçar o dinheiro.

Comecei a ler no aeroporto mesmo. Terminei de ler em 3 dias.

Esse livro me mostrou um novo jeito de se pensar sobre empreendedorismo que parece funcionar muito bem com meu novo estilo de vida. Um tipo de negócio que não precisa ser grande, não precisa de investimento externo (bootstraping), não precisa ocupar muito tempo da sua vida e ainda pode ser lucrativo.

O autor mostra, na prática, as etapas de planejamento e criação desse tipo de negócios e ilustra essas etapas com casos reais. Pessoas que começaram suas empresas com muito pouco e sem muitas pretensões e, hoje, conseguem trabalhar com o que gostam.

A leitura é muito leve, agradável e, por conta da abordagem prática usada, muito útil. O meu está cheio de marcadores de páginas com trechos interessantes.

Os capítulos falam sobre tipos de negócios, o tipo de investimento que você precisa fazer, que tipo de retorno você pode esperar, como planejar e iniciar as atividades, etc. Um dos capítulos fala até sobre franquias (ele diz que franquia é um emprego que você compra).

A tradução não é a melhor que já vi mas não compromete a leitura. Quem consegue ler em inglês pode aproveitar o preço mais baixo dos ebooks na Amazon.

The $100 Startup: Reinvent the Way You Make a Living, Do What You Love, and Create a New Future

A Startup de $100: Abra o negócio dos seus sonhos e reinvente sua forma de ganhar a vida.

Filtros bolha e a diversidade de opinião

Nos últimos dias tenho feito algumas experiências e estou tentando viver sem o Google. Sério… é bem difícil e tem algumas coisas que eles fazem que estão se provando insubstituíveis.

A razão para eu tentar me livrar do Google é o temor de ficar tão dependente de um serviço deles e eles simplesmente resolverem descontinuar como fizeram com o Code Search, Reader, entre outros. É muito mais uma questão de confiabilidade do que privacidade, monopólio, etc.

Uma das coisas difíceis de se substituir é o Google Search. Principal produto da empresa. Para essa tarefa eu escalei o DuckDuckGo que, apesar do nome inusitado, já havia se motrado um excelente buscador em testes que eu havia feito anteriormente.

O DuckDuckGo tem duas “funcionalidades” interessantes. Uma delas é um respeito maior à privacidade de seus usuários. A outra é a ausência de filtros bolha.

Quando fui avaliar melhor a questão relacionada a filtros bolhas meu cérebro tomou uma linha de raciocínio que seguiu em direção à diversidade de opinião e a tolerância que temos à essa diversidade.

Vou tentar usar fatos atuais para ilustrar a minha linha de raciocínio e para isso terei que trabalhar com assuntos polêmicos relacionados à amor, ódio, religião, ateísmo, homossexualismo, etc.

Também vou partir da premissa de que todo mundo na internet, hoje, tem opiniões fortes sobre todos os assuntos. Dos royalties do petróleo ao dinheiro gasto para mandar a Curiosity para Marte.

O conceito de “filtro bolha” que o Google Search implementa faz com que assuntos que tenham mais relação com o seu histórico de pesquisa tenha um ranking melhor do que algo que não “combine” com você.

O resultado desse comportamento é que o Google Search vai sempre lhe oferecer “mais do mesmo” ao longo do tempo e aquilo que diverge das suas opiniões vai simplesmente sumindo dos resultados criando uma “bolha protetora” de opiniões.

Nas redes sociais isso também acontece mas de uma maneira mais explícita: você oculta as opiniões divergentes, o sistema ‘aprende’ que você não gosta daquilo e nunca mais te manda informações daquele tipo (ou daquela pessoa).

Frequentemente me pego “censurando” alguns posts nas minhas timelines quase que de modo inconsequente.

Sou ateu (mesmo) e acho que todos podem crer ou, como no meu caso, não-crer, no que lhes deixam felizes.

Sou heterossexual mas entendo o homossexualismo sob o aspecto cientifico dos estudos que dizem que as pessoas são homossexuais e não se tornam homossexuais por opção (ou com o passar dos anos).

No espectro político eu piso um pouco mais à esquerda do que à direita e tenho vínculo com um partido político que representa essa posição. Apesar disso sei que existem virtudes na “direita” e pessoas extremamente inteligentes que trafegam nessa vertente.

A minha linha-mestra de pensamento: se você está feliz e não está me tornando infeliz você pode fazer e acreditar no que achar melhor.

Apesar disso sou humano e cometo erros de julgamento e avaliação.

Recentemente, com a chegada de um pastor evangélico fundamentalista à presidência da Comissão de Direitos Humanos da Câmara dos Deputados, as redes sociais estão fervendo com assuntos relacionados à cristianismo, laicismo, homossexualismo, racismo, e outros “ismos”.

Pra mim, na minha timeline, é um festival de surpresas e decepções com pessoas que fazem parte do meu “círculo virtual de amizades”. Até aí não tem nada de errado. O problema aparece é na escolha dos critérios que te fazem ficar surpreso ou se decepcionar.

Sendo ateu eu poderia me decepcionar com uma pessoa quando ela defende parcimoniosamente o discurso do tal pastor demonstrando trechos bíblicos que corroboram tais opiniões (mesmo sabendo que com trechos da bíblia é possível corroborar qualquer tese). Essa pessoa é crente e tem pra ela que esse livro é sagrado, logo, tem força maior que a “lei dos homens”.

Mas eu não posso me decepcionar com essa pessoa e censurá-la na minha timeline porque, com isso, estaria alimentando o meu filtro bolha e mandando a diversidade de opinião às favas. No lugar de censurá-la eu prefiro debater com essa pessoa ou simplesmente deixá-la com suas opiniões, afinal, ela deve ser feliz com aquele pensamento.

Agora vamos para outra hipótese: esse mesma pessoa que citou a bíblia me decepcionaria muito se usasse uma mentira, um estudo científico duvidoso, uma fonte de origem duvidosa, ou até mesmo usar desonestidade intelectual para, por exemplo, “provar que homossexualismo é errado”.

Eu tenho duas reações possíveis com pessoas que me decepcionam dessa forma. Se a pessoa é muito cara para mim eu rebato o post dela para tentar desmenti-lo. Se a pessoa “não cheira nem fede”, ela será censurada. Mas veja que eu censurei essa pessoa por ser desonesta e não por ser crente.

Qualquer tipo de censura cria o efeito “bolha” mas a bolha que eu criei é uma bolha de segurança para me proteger contra pessoas desonestas e não pra me privar da diversidade de opinião.

Além dessa censura aos desonestos eu também censuro, com menos frequencia, os “ativistas”. Censuro eles não pelo que pensam e defendem mas pelo excesso. É uma questão puramente prática: tenho um limite de tempo para ver a minhas timelines. Se elas estão monopolizadas pelos “ativistas” fica difícil ver os posts de todo mundo.

Além disso, ativistas, sejam felizes com o que pensam e defendem e me deixem ser feliz com o que penso e defendo. Parem de se comportar como Testemunhas de Jeová oferencendo a palavra do senhor.

Quanto ao caso do tal pastor: não acho que ele seja adequado para a tal comissão e acho que ele deveria sair de lá. Mas não devemos ser desonestos para atingir esse objetivo.

Não concordo com uma palavra do que dizes, mas defenderei até o ultimo instante seu direito de dizê-la.

Voltaire (ou não)

Desenvolvimento Python e Empreendedorismo