Categorias
Geral

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

Zoom de uma tela exibindo a saída do comando top do Unix em um terminal com fundo preto
Foto: Zack Smith

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” 😀

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

Usando o comando history

O Gustavo Straube também sugeriu usar o comando history em conjunto com o grep:

$ history | grep 'comando'

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 😀

Agradecimentos para o toti por ter feito me lembrar dessa dica 😀

Limpando a tela do console

O comando para limpar a tela do console e posicionar o prompt na primeira linha do terminal é:

$ clear

Mas você também pode usar uma combinação de teclas essa função:

  • CTRL-L no Linux
  • CMD-K no Mac OS X

você pode acionar essa combinação de teclas a qualquer momento. Mesmo depois de já ter digitado alguma coisa no prompt. Exemplo:

$ ls <ctrl+l></ctrl+l>

Vai limpar a tela e manter o comando ls que já foi digitado.

Eu já conhecia e usava isso mas o Adrian C. Miranda me lembro nos comentários.

Ú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

Voltando para o diretório anterior

Essa eu imaginava que todos soubessem mas descobri que muita gente desconhece. O comando cd que altera o diretório corrente aceita o parâmetro - (cd - que faz você voltar para o diretório onde você estava anteriormente.

~/Work/x$ cd ../y
~/Work/y$ cd -
~/Work/x
~/Work/x$ _

Dica: Você também pode usar “git checkout -” no git para voltar para o branch anterior.

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.

Categorias
Geral

Personal Python Style Guide

Foto com o zoom de uma tela exibindo um trecho de código escrito em Python em um editor de textos com syntax highlight.

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.

Categorias
Geral

Série Inteligência

capa dos 3 livros da série descrita no artigo

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

Recentemente 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 😀

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

Categorias
Geral

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)
Categorias
Geral

Meu ambiente de trabalho em 7 items

Fui convocado pelo @franciscosouza para listar 7 ítens do meu ambiente de trabalho… então aqui vai…

1. Triveos Tecnologia

A Triveos é a minha empresa e tenho, como sócio técnico, o pythonista Marcos Petry. Não chega a ser uma “equipe” mas já dá pra fazer um bom estrago ;D

Aqui na Triveos a gente não tem preconceito contra nenhuma tecnologia (nosso site e blog rodam em PHP e somos membros do Microsoft Bizspark).

Eu particularmente tenho algumas “birras” com alguns softwares que já me torturaram no passado: Trac, Nagios, Squirrelmail, Bazaar, etc.

2. Git, Github, Codebase

Nós gostamos muito de usar DVCS e adoramos o Github para hospedar nossos (poucos :/) projetos open-source. Gostamos das ferramentas de apoio à criação de grupos de desenvolvedores que eles oferecem.

Usamos o Git por conta do Github. Mas usaríamos Mercurial se o Bitbucket fosse tão bom quanto.

No nosso dia-a-dia a gente lida com projetos de clientes e/ou de código fechado e para esses projetos nós achamos melhor procurar um local mais “tranquilo” pra hospedá-los. Sem o oba-oba, “excessos” do Github e com um suporte mais “rápido” à eventuais problemas.

Então contratamos um plano no Codebase. Lá eles oferecem hospedagem de código com repositórios Git, Mercurial ou SVN. Também disponibilizam um sistema de Tickets/Milestones e Wikis para projetos.

3. Tecla, Webfaction e Linode

Para hospedagem em produção preferimos usar o Linode (e eu indico a todos que querem um serviço simples e de qualidade).

Mas em alguns projetos (leia-se Ludeos) temos algumas exigências relacionadas a comprovação de gastos. Nesses casos usamos o Cloud da Tecla. Eles são melhores que a Locaweb mas ainda são infinitamente inferiores a qualquer hosting similar nos EUA. E nem estou falando de preço (o pior deles, IMHO, é o sistema de cobrança).

Os sites mais simples (e blogs) ficam numa conta compartilhada simples no Webfaction. Para colocar um WordPress “no ar” com poucos cliques é uma baita ferramenta. Mas costumo notar certa lentidão no acesso às páginas de tempos em tempos.

4. Vim, Textmate e nada de IDEs

Uso principalmente o Vim mas me viro bem com o Textmate também. Dependendo da minha “vibe” eu uso um ou outro.

Recentemente passei a usar o MacVim mas ainda não estou me dando muito bem com ele. Vou insistir mais um pouco pra ver se me acostumo.

Nossos funcionários usam Eclipse+PyDev… engraçado isso… 😀

5. Python (… JS, Ruby, C, Shell Script, Java, PHP, …)

Aqui na Triveos é assim: se a bola foi lançada a gente mata ela no peito e chuta pro gol! 😀

É claro que a gente seria mais feliz usando só Python, mas não dá pra fazer isso sempre.

Para desenvolvimento web nós usamos Django mas já namoramos o Flask, o Repoze.BFG (Pyramid), e diversos outros frameworks web feitos em Python.

Já usamos jQuery (apesar de eu não gostar dessa biblioteca) e estou estudando YUI3 seriamente a algum tempo.

6. OS X e Ubuntu Linux

OS X pra criar e Ubuntu pra produzir em massa. 😀

Já usamos CentOS e Debian em ambientes de produção mas eu detesto lidar com software velho. Então adotamos uma alternativa mais “arriscada”? E usamos a última versão de Ubuntu disponível. Procuro sempre atualizar os ambientes de produção.

Instanciamos uma máquina com o Ubuntu mais novo “nas nuvens”, rodamos um comando de setup/deployment e pimba! servidor novo, com software atualizado e rodando…

…mas isso só é possível em projetos onde usamos “Continuous Deployment”… e ainda estamos aprendendo a fazer isso direito. Quando estivermos “fera” nisso pretendo escrever sobre o assunto aqui.

Mas se alguém quiser uma idéia do que planejo pode ver no artigo Python deployment tips do Lorenzo Gil.

7. Ambiente

Uso o Terminal.app (mas tenho planos de experimentar o iTerm) com bash configurado para modo vi no prompt.

Uso:

  • Marinho Brandão (@marinhobrandao)
  • Arthur Furlan (@arthurfurlan)
  • Marcos Petry (@petry)

… descreverem seus ambientes 😀

Categorias
Geral

A Web e o problema das senhas “clear text”

Foto: Christiaan Colen

Nos últimos dias o serviço Trapster avisou que 10 milhões de senhas dos seus usuários poderiam estar comprometidas. No ano passado a rede de sites de notícia Gawker passou pelo mesmo problema por um problema parecido.

E se formos voltar no tempo vamos descobrir que todo ano temos pelo menos 2 ocorrências similares em sites grandes. E isso vem acontecendo ano após ano desde que a Internet se tornou acessível entre “civis”.

Se todos os usuários usassem senhas diferentes para cada um dos serviços que usa na internet o estrago causado por esse tipo de situação seria bastante limitado. Mas não é isso o que acontece e, quando senhas “vazam” na internet o estrago pode ser gigantesco.

Problema antigo. Solução conhecida.

Em 1994 fui fazer estágio na Telesp no interior de São Paulo. Lá eu tive meu primeiro contato “sério” com um Unix. Era um SCO Unix que rodava num 386SX com 7 terminais seriais.

Enquanto eu estava aprendendo a usar o Unix eu vi que tinha um arquivo chamado /etc/passwd e, pelo nome, imaginei que lá eu encontraria as senhas de usuários do sistema.

Naquela época eu era “metido a hacker” e fiquei entusiasmado com a idéia de descobrir a senha de todo mundo que usava aquele servidor. Fiquei mais animado ainda quando vi que as permissões do arquivo permitiam que qualquer usuário examinasse seu conteúdo.

Quando abri o arquivo veio a decepção… no lugar onde deveriam ficar as senhas estava um “x”. Mas não me dei por vencido. Após estudar as manpages (que viam impressas em manuais imensos!) fiquei sabendo que as senhas não estavam lá. Elas estavam no arquivo /etc/shadow.

Com o ânimo renovado fui atrás desse arquivo. Mas dessa vez as coisas estavam um pouquinho mais difíceis… só o usuário root conseguiria ver esse arquivo.

Chegou a hora, então, de uma pitada de engenharia social… não vou contar como fiz porque foi muito fácil mas consegui a senha de root do sistema… hora de ver a senha dos outros usuários da Telesp e implantar uma mega-revolução na telefonia brasileira!… erm… menos…

Quando abri o arquivo tomei uma ducha de água fria definitiva. No lugar onde as senhas deveriam estar eu só um amontoado de caracteres que não se pareciam com senhas. Até poderiam ser as senhas dos usuários mas parecia muito improvável (e de fato não eram).

Descobri depois que o que estava armazenado ali era o resultado de uma espécie de “criptografia”. Ou seja, em 1992 os sistemas Unix já não armazenavam as senhas em texto puro. É bem provável que eles já não fizessem isso a muito mais tempo.

Estamos em 2011. Se depois de 19 anos eu armazenasse as senhas dos meus usuários em “texto puro” eu deveria ser chamado de irresponsável e incopetente. Se um invasor tivesse acesso à essas senhas eu deveria ser tratado como criminoso. No mínimo.

A solução

A única solução correta e infalível para armazenar senhas de forma segura é: não armazená-las.

Aí você deve estar perguntando: se eu não armazenar a senha do usuário como eu consigo verificar a senha dele durante sua autenticação?

Uma resposta “básica” seria: armazene o hash da senha.

Segundo o HowStuffWorks brasileiro:

“Hash é resultado da ação de algoritmos que fazem o mapeamento de uma seqüência de bits de tamanho arbitrário para uma seqüência de bits de tamanho fixo menor de forma que seja muito difícil encontrar duas mensagens produzindo o mesmo resultado hash (resistência à colisão ), e que o processo reverso também não seja realizável (dado um hash, não é possível recuperar a mensagem que o gerou).”

Existem vários algorítmos para cálculos de hash. Cada um deles possui um determinado tipo de aplicação. As funções de hash mais “famosas” são aquelas cuja aplicação está no campo da criptografia: MD2, MD4, MD5, SHA1, SHA256, …

Vou demonstrar o que acontece com o MD5:

$ echo "123mudar" | md5sum
642d8860fc6fe3126803ebdbe9974abd
$ echo "123mudar" | md5sum
642d8860fc6fe3126803ebdbe9974abd
$ echo "123mudor" | md5sum
fe294bbc902c287efb7acb20c8fdb67a

Note que sempre obtemos o mesmo resultado quando a senha é a mesma mas quando mudamos 1 único caracter o resultado do cálculo de hash muda completamente.

Tendo isso em mente podemos pensar em armazenar no nosso banco de dados apenas o hash da senha do usuário. Quando for preciso verificar a senha informada pelo usuário aplicamos a função de hash à ela e comparamos com aquela que está armazenada no banco de dados.

Perfeito não é? Problema resolvido, não? Não! Ainda falta uma pitada de “sal” nessa receita…

Salt – mais uma dificuldade para o invasor

Vamos supor que um invasor tenha acesso ao banco de dados da aplicação e ao hash das senhas…

Com esses hashes o usuário pode disparar um ataque baseado em dicionários ou até mesmo procurar pelos hashes no Google! Veja o que acontece com uma senha “fraca”:

$ echo "senha" | md5sum
6fd720fb42d209f576ca23d5e437a7bb

Agora procure por “6fd720fb42d209f576ca23d5e437a7bb” no Google e veja o resultado 😀

Para resolvermos esse problema devemos usar um “salt” para gerar o hash da senha.

Salt é uma sequência aleatória de bits que são concatenados à senha do usuário antes de gerar o hash (quanto maior essa sequência mais difícil será o trabalho do invasor).

Por ser uma sequência aleatória precisamos armazená-la junto com o resultado do hash para ser possível verificar a senha depois. Vamos à um exemplo “pythonico”

$ python
>>> import random
>>> import hashlib
>>> senha = "senha"
>>> salt = ''.join(chr(random.randint(65, 122)) for x in range(5))
>>> salt # Esse é o Salt!
'vGBAA'
>>> salt_senha = salt + senha
>>> salt_senha # salt + senha
'vGBAAsenha'
>>> hash = hashlib.md5(salt_senha).hexdigest()
>>> hash # Esse é o hash do salt+senha
'3607507cfa3f31b0cf10e83af947df97'
>>> armazenar = salt + "$" + hash
>>> armazenar
'vGBAA$3607507cfa3f31b0cf10e83af947df97'

Tente procurar pelo hash “3607507cfa3f31b0cf10e83af947df97” no Google agora… ou submeter esse hash à um ataque de dicionário… Você verá que aumentamos um pouco a dificuldade para descobrir a senha do usuário.

Esse é o procedimento usado por grande parte dos frameworks web que implementam alguma forma de armazenamento de senha (ex. django.contrib.auth) (ver atualizações 2 e 3). Ele é bastante seguro e podemos considerar isso satisfatório. Mas as coisas estão mudando…

A nuvem “do mal”

Com o advento da “computação na nuvem” chegamos à situação onde podemos comprar “poder de processamento” tal como compramos energia elétrica.

Antigamente se a gente tivesse um salt+hash em mãos era quase impossível (ou economicamente inviável) conseguir poder de processamento suficiente para submetê-los à um ataque de força bruta.

Mas as coisas mudaram e com 1 cartão de crédito e uma quantidade “viável” de dinheiro é possível contratar dezenas de “nós” de processamento na Amazon ECS, por exemplo, e colocá-los para “atacar” o nosso salt+hash.

Esse tipo de prática provavelmente já está sendo usada por alguns invasores pelo mundo e aparentemente não existe uma solução definitiva para esse tipo de situação.

O que existe são medidas que você pode adotar para dificultar um pouco mais a vida dos vilões 😀

Uma delas é substituir o algoritmo de hash (MD5/SHA1) por outro algorítmo mais apropriado para o nosso uso.

O problema em usar os algorítmos MD5 e SHA1 para calcular os hashes de nossas senhas é que eles são muito eficientes e rápidos. As principais aplicações desses algorítmos exigem que eles sejam rápidos (ex. assinatura digital de um arquivo gigantesco).

Como eles são muito rápidos é possível disparar um ataque de força bruta e testar muitos hashes em um curto espaço de tempo. Como as plataformas na “nuvem” cobram por tempo de uso podemos quebrar uma senha à um custo relativamente baixo (ou viável economicamente).

Se trocarmos esses algorítmos por um que seja muito mais lento obrigamos o invasor a gastar mais poder de processamento (e consequentemente mais dinheiro) para descobrir nossa senha.

Um dos métodos mais indicados, hoje, é o bcrypt (blowfish). Existe implementações desse algorítmo para diversas linguagens:

E como eu sei se um site armazena minhas senhas em texto puro?

Não é possível saber com 100% de certeza se um site ou serviço armazena as suas senhas em “texto puro”, portanto, o melhor mesmo é criar o hábito de usar senhas diferentes em cada um dos serviços (só tente não anotá-las em papéis! :D).

Mas apesar de não ser possível ter certeza se o serviço em questão é desenvolvido por um irresponsável é possível buscar indícios dessa irresponsabilidade:

  • Receber um e-mail de confirmação de cadastro onde sua senha está presente – Se ele está te mandando um e-mail com sua senha é grande a possibilidade dela ser armazenada da mesma forma.
  • Use a opção “esqueci minha senha” dos sites para testar – se você usar essa opção e o site te mandar um e-mail (ou mostrar na tela) a sua senha é porque eles tem a sua senha “original” armazenada em algum lugar. O correto é receber um link para *resetar* sua senha.

Implicações no “mercado”

Nós que trabalhamos com web e somos entusiastas da idéia “da nuvem” devemos condenar a prática de armazenar dados sensíveis do usuário de forma tão irresponsável. Cada notícia que surge dando conta de vazamentos dessas informações prejudica todos os serviços. Para um leigo é a segurança “da internet” que é falha.

Se você é um empresário ou desenvolvedor sério e responsável deve cuidar da segurança dos dados dos seus usuários com todo o cuidado e, sempre que ver outra empresa trabalhando de outra maneira você tem a obrigação de condená-la pois ela também está, indiretamente, prejudicando o seu negócio.

Atualização:

O meu amigo Guilherme Manika postou um link para um artigo onde a equipe do Gawker relata o problema ocorrido com as senhas de seus usuários.

Pelo que entendi eles armazenavam o hash das senhas usando a função crypt(3) e um salt com apenas 12 bits que, como disse, é muito pouco para os padrões de ataque atuais.

Então, em 2008, eles modificaram o sistema para usar o bcrypt() também. Mas, aí a ‘burrada’ deles: eles continuaram gerando o hash com crypt(3) e armazenando no mesmo lugar que os hashes bcrypt() pra manter compatibilidade retroativa!

Segundo um e-mail que circulou numa lista de segurança, 748.081 usuários tinham as senhas armazenadas com crypt() e 195.178 tinham as senhas armazenadas com crypt() e bcrypt(). Total: 943.259 usuários afetados. Quase um milhão de pessoas.

Atualização 2:

O framework Django, ao contrário do que disse, não usa bcrypt() para gerar o hash das senhas armazenadas. No lugar disso ele usa os algoritmos PBKDF2 + SHA256 conforme recomendações do NIST (pdf). Eles também usam outras técnicas complementares para tornar o sistema mais seguro como um comparador de strings em tempo constante.

Atualização 3:

O artigo faz muitas referências à bcrypt() que era o algoritmo recomendado pela maioria dos especialistas na época em que esse artigo foi escrito. Acontece que nesse mundo da tecnologia as coisas vão evoluindo e melhorias vão sendo sugeridas. Apesar disso o uso de bcrypt() é “bom o suficiente” e, por isso, manterei o texto original.

Caso você queira seguir as recomendações mais recentes o melhor é usar PBKDF2+SHA256 (+ algoritmos de comparação de strings em tempo constante) conforme indicado na Atualização 2 acima.

Se você se interessa pelo assunto, quiser se aperfeiçoar e consegue se virar bem com o inglês eu recomendo o curso (gratuito) de Criptografia de Stanford no Coursera.

Categorias
Geral

Arqueologia: eu e Tron

Quando eu assisti o filme Tron pela primeira vez eu delirei. Imaginem que eu era uma criança com 5 ou 6 anos. (Explico: Nasci em 77, o filme foi lançado em 82. Assisti o filme na TV, logo, um ou dois anos depois do lançamento do mesmo nos cinemas).

Nessa época eu sequer tinha ganhado meu Atari (primeiro ‘computador’ que eu teria) e o mais próximo que tinha chegado de um videogame foi num fliperama onde meu pai havia me levado (e de uma vaga lembrança de um Telejogo Philco/Ford que um tio rico tinha).

Sim, isso funcionava e era até divertido

Mesmo assim… O filme me marcou tão profundamente (ui!) que, tempos depois, quando eu tive acesso ao meu primeiro computador (um MSX Expert da Gradiente que tenho funcionando até hoje) a primeira coisa que fiz foi tentar programar o jogo das ‘bikes’ pra ele.

Expert igualzinho ao que eu tenho

Mas tinha um problema… eu não sabia programar nada! Então meu pai me matriculou numa escolinha que ensinava programação (LOGO e Basic Apple). Eu chegava da aula todo dia e tentava criar o jogo no meu computador. E demorou até eu ter algo que funcionasse.

Algum tempo depois ganhei um livro onde, em um capítulo, eles implementavam o jogo com o nome “Pedalando”. Fui todo animado ler o código fonte deles pra ‘roubar’ algumas melhorias e tive um sentimento misto de decepção e orgulho ao ver que a implementação deles era inferior à minha (eu tenho esse livro também mas ele está num depósito tão entulhado que deu preguiça de pegar).

“A edição que eu tenho tem capa azul e uma tartaruga Logo na capa!

O tempo passou, as fitas cassete onde gravava essas coisas mofaram (literalmente) e eu acabei perdendo essa versão do jogo.

Mas a minha mania de implementar “Tron” em todos os computadores, sistemas operacionais e linguagens de programação onde tinha acesso não se perdeu.

Tela inicial do jogo (note o meu dom para o design)

Entre 1990 e 1994 eu fui desenvolvendo a última versão de Tron que implementei. Não demorei 4 anos pra desenvolvê-la mas ao longo desses 4 anos fui ‘evoluindo’ minhas habilidades como programador e usava esse código para testar várias coisas novas.

Enfim. Pra quem quiser ver o código fonte é só visitar o repositório dele no Github. Ele foi desenvolvido com Turbo Pascal 6.0 e depois com Turbo Pascal 7.0. Não preciso dizer que o código é velho, não funcionará em nenhum computador que use um sistema operacional ‘moderno’. Se você tiver uma imagem com MS-DOS em algum lugar é provável que as coisas funcionem. Os arquivos com as músicas (no formato .mod) não estavam mais nos meus arquivos, portanto, coloquem qualquer uma ou joguem sem música :D)

Mas a história não acaba aqui…

Sempre gostei de música eletrônica e andava de um lado pra outro com discos do Kraftwerk, Bomb the Bass, House & Remix Internacional, etc debaixo do braço.

Homework (acreditam que me roubaram o CD e só tenho o encarte?)

Alguns anos depois disso tudo eu tive uma época onde queria ser “DJ” e um amigo meu que curtia um tipo de som mais ‘underground‘ me emprestou um CD chamado Homework de um grupo chamada Daft Punk. Gostei tanto do CD que acabei comprando desse meu amigo (por uma grana alta!).

E os capacetes tem LEDs que exibem mensagens 😀

Desde essa época venho acompanhando o trabalho da dupla de franceses que usam capacetes muito malucos. Gostei de muita coisa que eles fizeram. Outras coisas não gostei tanto assim. Mas no geral sou fã do trabalho deles.

Pretendo assistir a estréia no IMAX 3D! 😀

Agora vocês imaginam o meu estado de ansiedade pra assistir Tron Legacy.

Trata-se “apenas” da continuação do filme que mudou a minha vida e que determinou tudo o que eu faria até hoje, com uma trilha sonora de uma dupla de músicos da qual eu sou fã desde a época em que eles eram considerados ‘underground’.

Filmes como Guerra nas Estrelas, Matrix, Explorers, etc foram muito importantes na minha infância mas Tron fez toda a diferença.

Categorias
Geral

E os programadores, onde erram?

O @marionogueira provocou e eu vou responder.

Carreira de programador

Mas antes vou explicar porque eu compartilho da visão de que o trabalho de desenvolvedor guarda semelhanças com o trabalho de um artista (importante dar destaque à palavra “semelhança” para não pensar que as coisas são iguais).

Como programador você pega uma especificação abstrata que se parece com uma ‘inspiração’ e começa a trabalhar nela até obter algo ‘bruto’, aí você vai lapidando (iterando) sobre esse trabalho, simplificando, e aproximando o software daquela inspiração (especificação).

Nesse processo o programador vai deixando seu “estilo” no código. Na escolha de algorítmos, de estruturas de dados, nos textos de comentários e até mesmo no “Coding Style”. Essas características são tão notáveis que depois de um tempo é possível identificar o autor do código mesmo quando ele não está ‘assinado’.

Uma diferença importante entre o trabalho de artistas e de programadores é que raramente vemos o trabalho em equipe (times) no universo das artes e o mesmo é quase uma regra no mundo do software.

Mas daqui para frente eu vou falar sobre um tipo específico de artistas: aqueles que trabalham sob encomenda pintando retratos de reis e nobres para garantir o seu sustento. E para ilustrar o meu raciocínio vou usar uma das obras de arte mais conhecidas no mundo: a Monalisa.

A Monalisa (La Gioconda) foi uma obra encomendada por Francesco del Giocondo a Leonardo Da Vinci. Existe muitas versões, mitos e mistérios que cercam essa obra mas vamos nos ater à “história oficial”.

Francesco passou uma especificação para Da Vinci (ele queria um retrato de sua esposa Lisa Gherardini) e provavelmente especificou prazo e preço. Ou talvez tenham feito um contrato de escopo aberto? Não sei, não estudei essa história muito a fundo.

Leonardo Da Vinci, então, fez os primeiros esboços e foi apresentando esses esboços ao contratante. Talvez não tenha feito isso porque o contratante confiava plenamente na capacidade de entrega dele. Mas não teria sido vergonha se tivesse que apresentar os esboços no meio da execução do projeto.

O resultado final foi um trabalho encomendado, executado no prazo combinado, à um custo determinado e que, mesmo assim, era uma obra de arte.

Curiosamente o escritório da Triveos é vizinho de uma escola de pintura. Todo dia passo em frente à sala de aula e vejo o trabalho dos alunos. É fácil perceber que não tem nenhum Leonardo Da Vinci ali (por enquanto). Falta-lhes experiência. Prática. Com o tempo e empenho eles se transformarão em bons artistas. Talvez gênios.

O mesmo acontece com os programadores. Só com a prática, a experiência, e com o domínio da técnica um programador se tornará um ‘artista’ de verdade.

Mas voltando à questão levantada pelo @marionogueira…

O ‘mundo’ está errado no gerenciamento dos programadores quando eles mudam escopo, prazo e custo dos projetos a todo o instante e ainda exigem uma obra de arte como resultado do trabalho. Ou quando não permitem que o ‘artista’ trabalhe ao seu modo.

A Monalisa seria uma obra de arte se, durante o seu desenvolvimento, o contratante desse palpites sobre as cores e cenários deveriam ser usados na obra?

Mas os programadores também erram!

Erram quando aceitam o desafio de desenvolver uma obra de arte sem ter o domínio adequado da técnica, a prática e a experiência necessária para transformar aquela especificação em arte.

Em projetos ideais onde o escopo é claro, o prazo é razoável e custo está sob controle os programadores falham quando não compreendem que, mesmo tendo sido encomendada, a ‘obra de arte’ é dele também. Sem essa compreensão eles deixam de se comprometer com sua execução.

Mesmo tendo sido encomendada, Da Vinci não fez a Monalisa ‘nas coxas’. Ele fez o máximo possível para entregar uma obra de arte única. Isso fica claro em projetos open-source onde a obra e o nome do artista fica público.

Um artista não precisa de foco e disciplina para se inspirar. Aliás, isso pode até atrapalhar. Mas para executar a obra é necessário muito foco e muita disciplina. Principalmente se a obra foi encomendada e tem custos e prazos pré-estabelecidos.

O programador falha quando ele não tem foco e disciplina no seu trabalho. Twitter, MSN, GTalk, IRC e outros sugadores de foco, hoje, ficam mais tempo em funcionamento do que a IDEs, editor de textos e outras ferramentas de desenvolvimento. Eu sei. Eu vivo isso.

Fora isso eles podem errar em outras questões que envolvem relacionamento interpessoal, trabalho em equipe, ética, etc. Mas nessas questões todos podem errar.

Categorias
Geral

Como garantir um emprego de desenvolvedor

uma mesa repleta de peças de lego espalhadas
Foto: Robert Lowe

Post rápido e ligeiro com uma lista de atributos que certamente vão garantir a sua vaga como desenvolvedor em qualquer empresa que valha a pena trabalhar.

Cada atributo tem um dos graus de importância abaixo (do mais importante para o menos importante):

  1. Vital – característica mais do que essencial para vagas de desenvolvedor ou para qualquer outro tipo de posição.
  2. Essencial – característica imprescindível para um desenvolvedor.
  3. Importante – característica importante mas não imprescindível. Pode-se contratar um desenvolvedor que não tenha essa característica desde que haja um compromisso do mesmo em desenvolvê-la.
  4. “Plus” – não faz muita diferença mas pode ser uma característica que pode desempatar (a favor de quem a tem) numa disputa entre dois ou mais candidatos.
  5. Desnecessária – não faz diferença alguma.
  6. Condenável – característica que pode depor contra a sua candidatura.

O que está escrito aqui é a minha visão sobre o assunto. Algumas empresas contratantes podem divergir no grau de importância de cada atributo. Outras, por questões legais, podem exigir determinada característica listada como:

  • Comunicação (vital) – comunicação escrita e verbal, capacidade de argumentação e de expressar idéias e conceitos.
  • Prazer em programar (vital) – você programa nas horas vagas? Não? Então desista. Corra atrás de trabalhar com aquilo que você faz nas horas vagas. Todos ficarão gratos.
  • Prazer por aprender coisas novas (vital) – Veja… eu disse “prazer por” e não “interesse em”.
  • Inglês para leitura (vital) – não dá mais tempo de esperar por traduções de documentação.
  • Programação (essencial) – tem que saber teoria e prática. Conhecer algoritmos, estruturas de dados, conceitos de OO, paradigmas de programação, teoria da computação, matemática, …
  • Familizarização rápida com ferramentas (essencial) – você é capaz de corrigir um bug numa aplicação escrita numa linguagem que você não conhece em quanto tempo? Consegue produzir código numa linguagem nova em menos de uma semana?
  • Inglês para escrita (essencial) – grande parte dos softwares, bibliotecas e sistemas que usamos hoje são desenvolvidos por estrangeiros. Freqüentemente precisamos trocar um e-mail com esses desenvolvedores.
  • Conhecer bem ao menos uma linguagem (essencial) – essa linguagem varia de acordo com o que você deseja desenvolver, mas ela tem que ser uma espécie de ‘segundo idioma’ seu. No meu caso essa linguagem é Python, mas poderia ser outra.
  • Inglês conversação (importante) – grande parte dos lugares bacanas pra se trabalhar, hoje, são estrangeiros, tem filiais fora do país ou estão contratando estrangeiros pros seus times. Poder conversar com eles é importante.
  • Ter familiaridade com ‘linguagens chave’ (importante) – algumas linguagens de programação estão presentes em tantos lugares que não é mais possível desconhecê-las: assembly de pelo menos 1 plataforma, C, Shell Script, linguagem funcional (fico devendo essa :D), linguagem OO (Java, Smalltalk, Python, Ruby, …).
  • Participação em projetos FLOSS (importante) – universo perfeito para exercitar, experimentar, participar, desenvolver, aperfeiçoar, … todas as características listadas aqui. Alguns lugares onde trabalhei sequer pedia curriculums para contratar um desenvolvedor e usavam só a participação dos mesmos em projetos FLOSS
  • Formação acadêmica (plus) – desde que seja numa boa faculdade (USP, Unesp, UNICAMP, UF*, UTF*, PUC*, …) podem indicar que os alunos aprenderam alguns fundamentos importantes de programação. O convívio social dos alunos para estudo, execução de projetos e trabalhos também acrescenta.
  • Certificações (desnecessária) – empresas que pedem ou avaliam certificações não podem ser empresas onde valha a pena trabalhar. Empresas que usam certificações são aquelas que são incapazes de avaliar corretamente os candidatos e ‘terceirizam’ essa tarefa para as entidades certificadoras. Uma empresa incapaz de avaliar um candidato não pode ser capaz de lhe dar boas condições de trabalho.
  • “Corporacionismo” (condenável) – profissionais que falam “frases que agregam valor e aumentam a sinergia do time junior de colaboradores” ou que acham fundamental a existência de uma regulamentação no mercado de trabalho de TI geralmente são aqueles que não querem ou não conseguem se destacar como desenvolvedor por conta própria e precisa de uma ‘mãozinha’ do governo pra isso.

Esse artigo descreve algumas características que um desenvolvedor deve ter para conseguir um emprego. Mas se o desenvolvedor quiser empreender e montar o seu próprio negócio, ele precisa das mesmas características? Sim, mas com graus de importância diferentes. Além desses atributos são necessários alguns outros que tentarei abordar em outro artigo.

Categorias
Geral

Desafios e Desafio #1

Sempre gostei de desafios do tipo ‘quebra-babeça’ que podem ser feitos com um lápis/caneta e um pedaço de papel qualquer.

Conheço uns bem legais, frequentemente encontro alguns desafios novos e vou começar a postá-los aqui pra outras pessoas que também gostam desse tipo de brincadeira.

Se você conhecer algum desafio que siga essas linhas, deixe um comentário com a dica que eu coloco ele aqui com os devidos créditos.

No fim do ano o colaborador mais ativo (que enviar mais desafios) ganha um jogo criativo da Gemini da escolha do ganhador.

O desafio de hoje é o seguinte:

O objetivo é ligar os números iguais sem que nenhuma linha cruze com a outra.

A resposta está no vídeo abaixo (áudio em inglês):