Você pode ser um programador cuidadoso. Usa Linux. Criptografa o disco. Tem senha forte e única em todo lugar. Ativa two factor authentication sempre que pode. Não baixa software pirata. Só instala coisa de repositório oficial. Usa firewall. Acesso por chave. Ambiente bem configurado. Tudo bonito.

E ainda assim pode tomar uma pancada feia.

Porque basta um npm install, um uv add, um pip install, um cargo add, um composer install, um go get, um mvn install para você baixar e executar código de terceiros dentro do seu ambiente. E não estou falando só de bibliotecas obscuras. Estou falando de ecossistemas inteiros baseados nisso.

Ataque de supply chain é isso: em vez de invadir diretamente o seu sistema, o atacante contamina algo em que você confia para chegar até você pela porta da frente.

Ano passado já tivemos vários casos chamando atenção no ecossistema JavaScript. E, agora, no fim de março, veio um dos mais assustadores: o caso do Axios. As versões comprometidas foram 1.14.1 e 0.30.4, publicadas em 31 de março de 2026. O pacote malicioso puxava uma dependência falsa e executava um postinstall capaz de instalar um RAT em Linux, macOS e Windows. Não era “só uma biblioteca vulnerável”. Era malware sendo entregue por uma ferramenta que milhões de programadores usam normalmente. O Axios, como pacote, passa de 70 milhões de downloads semanais. E, até onde consegui apurar, ninguém publicou o número exato de downloads das versões comprometidas.

E isso não é exclusividade de Node.js. O mesmo tipo de problema aparece em outros ecossistemas. Há poucos dias, o próprio PyPI publicou um relatório sobre os ataques envolvendo LiteLLM e Telnyx, com orientações práticas para reduzir risco. (Blog do PyPI)

O ponto mais importante aqui é o seguinte: ambiente de desenvolvimento e pipeline de CI também são alvo.

Muita gente pensa em segurança de dependência como se o risco estivesse só em produção. Não está. No caso do Axios, o momento crítico era o npm install rodando em máquina de desenvolvedor e em pipeline automatizada, com potencial de capturar segredos, tokens e credenciais. No caso recente do LiteLLM, os relatos públicos falam em roubo de variáveis de ambiente, chaves SSH, credenciais de cloud, tokens e segredos de infraestrutura. (Microsoft)

E se você foi comprometido?

Aí atualizar a versão não basta.

Você deve assumir comprometimento. Isso normalmente significa isolar a máquina, investigar o host, rotacionar senhas, certificados, chaves SSH, tokens e outras credenciais. Em muitos casos, a medida mais prudente é recriar completamente o ambiente. Sim, “recriar completamente” significa formatar e reinstalar o sistema operacional. Supply chain não é bugzinho. Pode ser cavalo de troia dentro da sua estação de trabalho.

A comunidade está procurando soluções, e algumas coisas boas realmente avançaram. Desde 1º de janeiro de 2024, o PyPI passou a exigir 2FA para todos os usuários que fazem ações de gerenciamento ou upload. Também temos iniciativas como Trusted Publishers, SBOM, verificação de integridade e outras melhorias importantes. Mas não dá para sentar e esperar que o ecossistema resolva tudo sozinho. A responsabilidade pelos seus projetos continua sendo sua.

E aí vem a pergunta inevitável: então o que você vai fazer? Parar de usar open source? Reescrever tudo do zero?

Claro que não.

Usar bibliotecas de terceiros é inevitável. O problema não é esse. O problema é usar sem critério nenhum.

O fato de esse risco ser inevitável não significa que ele seja incombatível. Dá para reduzir muito a superfície de ataque. E, em segurança, reduzir risco já muda completamente o jogo.

Na prática, eu colocaria isso em três frentes.

1. Use menos dependências

Programadores adoram regra absoluta. A vida quase nunca funciona assim.

Você provavelmente come açúcar, mas não vive de colheradas de açúcar. Com dependências é a mesma coisa. Não é questão de abolir. É questão de moderação.

Tem uma galera que se lambuza.

Instala biblioteca para fazer coisa que a linguagem já faz. Puxa pacote para resolver detalhe minúsculo. Aceita árvore de dependências gigantesca em troca de uma conveniência ridícula.

Olha o caso do Axios. É uma biblioteca excelente. Não tenho nada contra. Mas, se a sua aplicação faz três requisições HTTP em meia dúzia de pontos, o fetch resolve. Você realmente precisa de mais uma dependência?

Em Python acontece o mesmo. requests e httpx são ótimos. Mas não existe nada de errado com urllib quando ela basta para o que você precisa.

Quer um exemplo didático do exagero?

Tem pacote no npm para verificar se um número é ímpar. Sim, isso existe. Chama-se is-odd. Você pode olhar e rir. Mas o ponto é sério: cada dependência adicionada é mais uma cadeia de confiança, mais um pedaço de código de terceiros, mais uma oportunidade de compromisso.

Não estou dizendo para nunca usar dependência. Estou dizendo para tratá-la como custo, não como brinde.

Cada pacote precisa se justificar.

2. Congele dependências

A segunda medida é congelar dependências.

Isso reduz muito a janela de exposição a publicações futuras maliciosas e ainda te dá reprodutibilidade. Em outras palavras, evita que seu projeto mude de comportamento sozinho só porque alguém publicou uma nova versão de um pacote ontem à noite.

Vamos demonstrar.

Eu uso mise-en-place porque trabalho com várias linguagens. Em Python temos pyenv e uv. Em Node temos nvm, volta, pnpm, fnm. O mise-en-place me permite ter uma ferramenta só para gerenciar ambientes e versões de linguagem. Este artigo não é sobre mise-en-place, mas, se você quiser, eu posso escrever outro só sobre isso.

Vou criar uma pasta nova e inicializar um ambiente com Python e Node:

mkdir teste1339
cd teste1339/
misemodel python="3.14" node="24.14" -f

Pronto. Agora, nessa pasta, eu tenho Python 3.14 e Node 24.14 disponíveis para programar.

Vamos instalar um pacote super útil no npm:

npm install is-odd

E um pacote super útil no Python:

uv add requests

Perceba que usei uv, não pip. Fiz isso porque quero trabalhar com locking de dependências de forma mais séria. Depois disso, executo:

uv lock

E agora um ls:

main.py              package-lock.json  pyproject.toml  uv.lock
node_modules         package.json       README.md

Em Node, temos package.json e package-lock.json. Em Python, temos pyproject.toml e uv.lock.

Esses arquivos registram a árvore resolvida de dependências e mecanismos de integridade usados na reinstalação. Se, em algum momento, a integridade esperada não bater, a instalação falha. Isso é exatamente o tipo de atrito que você quer quando a alternativa é executar código adulterado.

Agora imagine que eu edite um lockfile e troque manualmente o hash de algum artefato. Depois disso, simulo uma instalação nova do projeto.

Esse detalhe é muito importante: quando você trava corretamente a árvore de dependências, seu projeto não passa automaticamente a usar uma nova publicação que apareceu no registro depois. Se amanhã alguém comprometer uma nova versão daquele pacote, meu projeto não vai sair correndo para baixá-la sozinho. O lockfile reduz muito essa superfície de ataque de supply chain, desde que eu não atualize cegamente.

E, de brinde, você ganha estabilidade funcional. O mesmo projeto instala do mesmo jeito hoje, amanhã e no mês que vem.

Vale um aviso importante: lockfile não é escudo mágico. Ele não salva você se a primeira instalação já aconteceu numa versão comprometida. Mas ele reduz muito o risco de contaminação por atualizações futuras inesperadas.

3. Desacelere atualizações

Aqui está um ponto que quase ninguém gosta de ouvir.

Você não deve atualizar dependência automaticamente sem revisão humana.

Isso não é produtividade. Isso é risco operacional travestido de conveniência.

Claro que você também não vai ficar congelado para sempre na mesma versão de tudo. Bibliotecas recebem correções de segurança, correções funcionais e melhorias legítimas. O problema não é atualizar. O problema é atualizar no susto, sem contexto e sem tempo de observação.

O ideal é separar as atualizações em dois grupos.

O primeiro grupo são as atualizações críticas de segurança. Essas devem ser avaliadas e aplicadas o quanto antes. Normalmente elas vêm acompanhadas de boletins, advisories, CVEs, discussão pública e muita atenção em cima do problema. Nesses casos, o risco de não atualizar costuma ser maior do que o risco da mudança.

O segundo grupo são as atualizações regulares. Nessas, eu prefiro uma regra simples: não adote automaticamente uma versão recém-lançada.

Se hoje é dia de atualizar e um pacote saiu ontem, eu não quero ser o primeiro da fila. Prefiro instalar a anterior ou esperar um pequeno intervalo. Esse cooldown diminui a chance de eu puxar uma versão publicada às pressas, com erro grave, ou até uma versão maliciosa que ainda não foi detectada. O próprio PyPI recomendou locking e dependency cooldowns depois dos incidentes recentes.

A mesma lógica vale quando você começa um projeto novo.

Vai adicionar uma dependência? Olhe quando aquela versão foi publicada. Se ela é novíssima, dê um passo para trás. Não precisa ser o early adopter de tudo dentro do ambiente que guarda as chaves do seu negócio.

Não existe risco zero em supply chain

Esse talvez seja o ponto mais importante de todos.

Você não vai eliminar ataques de supply chain da sua vida. Isso não existe.

Se você desenvolve software moderno, você depende de código de terceiros. E, se depende de código de terceiros, depende também da segurança dos mantenedores, das contas deles, dos pipelines deles, dos registros, dos mirrors, dos plugins, das ferramentas e do processo inteiro.

Só que entre “não existe risco zero” e “então tanto faz” existe um abismo.

Usar menos dependências, travar a árvore de instalação e desacelerar atualizações já muda bastante o seu perfil de risco. Você para de ser o alvo mais fácil. E, em segurança, isso conta muito.

Ataques de supply chain são perigosos justamente porque exploram confiança. Eles entram no seu ambiente usando a mesma porta pela qual entram as coisas boas. Por isso a defesa não pode ser ingenuidade, nem pânico. Tem que ser critério.

Não é sobre abandonar open source. É sobre parar de tratar dependência como se fosse decoração.

Cada pacote que você adiciona aumenta sua superfície de ataque. Cada instalação é um ato de confiança. E confiança, em computação, precisa ser administrada com muito mais cuidado do que a gente costumava admitir.

O post Evitando ataques de supply chain apareceu primeiro em Elcio Ferreira.

Acontece que a webcam interna continua disponível. Isso poderia ser algo bom, certo? Bem, não exatamente… Às vezes, sem nenhum motivo, vou entrar numa reunião via Zoom ou Google Meet e a webcam interna é selecionada automaticamente. Então, ao invés dessa imagem:

Quem está na chamada acaba vendo isso:

Além do óbvio problema na qualidade da imagem, essa câmera ainda me pega de surpresa porque o notebook fica ao lado do meu monitor, então fica esse enquadramento acidental que você está vendo aí. É por isso que eu resolvi desabilitar a webcam interna.

Como descobrir o identificador da câmera

O primeiro passo para fazer isso é descobrir qual é o identificador do fabricante e do produto da minha câmera. Para isso, usei comando lsusb no terminal, que me deu essa saída:

Mas, peraí, porque lsusb? Sim, é estranho, mas a câmera interna, no meu e em vários outros modelos de notebook, é um dispositivo USB. Está ligada, por dentro, a uma interface USB da placa mãe. Vai entender…

Na segunda linha da saída acima, você pode ver a webcam interna listada, com o nome “Silicon Motion Web Camera”. E logo antes do nome, o identificador do produto: 2232:1080. Todos os dispositivos USB seguem esse padrão, os quatro primeiros dígitos são a identificação do fabricante, os quatro últimos são a identificação do produto.

Como desabilitar a webcam

Com esse código, no diretório /etc/udev/rules.d/ você vai criar um arquivo com uma regra para desabilitar a webcam interna. O nome deve começar com um número, que define a ordem de execução, e terminar com a extensão .rules. No meu caso, eu usei o nome 80-generic-webcam-remove.rules.

Se você não sabe como criar um arquivo no diretório /etc/, pode abrir um editor com o comando:

sudo nano /etc/udev/rules.d/80-generic-webcam-remove.rules

O conteúdo, no meu caso, ficou assim:

# ID 2232:1080 Generic Web Camera should be disabled
ACTION=="add", ATTR{idVendor}=="2232", ATTR{idProduct}=="1080", RUN="/bin/sh -c 'echo 1 >/sys/\$devpath/remove'"

Claro, substitua os números 2232 e 1080 no código acima pelos da sua webcam.

Salve e feche o editor. Se estiver usando nano, pressione CTRL+X, seguido de Y e Enter.

Reinicie seu computador e pronto, isso vai desabilitar a webcam interna em seu notebook.

O post Desabilitar webcam interna do notebook no Linux apareceu primeiro em Elcio Ferreira.

Sim!

No Windows, basta associar arquivos .py ao Python. Acredito que o instalador do Python para windows já faz isso. Feito isso, duplo clique no arquivo .py vai executá-lo.

No Linux, Mac, FreeBSD e assemelhados, basta colocar, na primeira linha do seu script:

#!/usr/bin/env python

Em seguida, torne seu script executável com o comando:

chmod +x seuscript.py

Claro, troque “seuscript” pelo nome do seu arquivo. Pronto, ele é executável. Você pode executar com:

./seuscript.py

Diferente do windows, a extensão não precisa ser .py, nem precisa ter extensão. Além disso, você pode mover o script para qualquer lugar no PATH do sistema e poderá executá-lo de qualquer diretório, sem precisar de ./ no início do comando. Por exemplo, pode fazer:

sudo mv ./seuscript.py /usr/local/bin/seucomando

Em seguida pode executar apenas:

seucomando

Sem ./ e em qualquer diretório.

O post Como tornar seu script Python executável apareceu primeiro em Elcio Ferreira.

Seria 2019, finalmente, o “ano do Linux no Desktop”?

Eu não certeza das implicações disso.

Eu sei que o que você esperava era a popularização do Gnome. Ou do KDE, ou XFCE, ou Enlightenment, ou Mate… Tanto faz, certo? Não importa qual interface gráfica, se o coração for Linux.

Então, será que faz diferença se a interface é Windows ou ChromeOS? O resultado final é que você vai poder escrever aplicações baseadas no Linux para rodar em todo lugar.

E, sinceramente, a web já tinha tornado essa discussão meio irrelevante.

Exceto para nós, programadores, que vamos poder desenvolver usando qualquer sistema operacional. Para o resto do mundo, a maior parte do tempo, o sistema operacional é o navegador.

O post O ano do Linux no Desktop (não como você esperava) apareceu primeiro em Elcio Ferreira.

Então, se você usa Linux, confira se você tem o Samba instalado. Se tiver, confira a versão menor (aquele terceiro número no código da versão). Se você estiver usando uma das seguintes, você está seguro: 4.6.4, 4.5.10 ou 4.4.14.

Se não. Você pode fazer uma das seguintes coisas:

1. verificar se há atualização do Samba para sua distribuição, e se a versão mais atualizada é uma dessas acima; ou
2. baixar o código fonte e compilar o Samba você mesmo, de preferência da versão 4.6.4; ou
3. desligar o serviço vulnerável, adicionando ao seu smb.conf a linha abaixo:

   nt pipe support = no

   E em seguida reiniciando o Samba; ou

4. desinstalar o Samba

A última alternativa pode parecer a mais preguiçosa, e talvez você simplesmente não possa cogitá-la. Mas eu recomendo que você se pergunte, antes de qualquer outra atitude: eu preciso mesmo desse serviço? Dessa vez foi uma falha no Samba, mas praticamente todo dia saem atualizações de segurança para os diversos softwares e serviços que você pode instalar em seu sistema. Cada software não utilizado que você mantém instalado aumenta suas chances de ter problemas de segurança e suas preocupações com atualizações de versão.

Nesse caso, menos é mais. Reduza os pacotes que você tem instalados aos essenciais, removendo tudo o que você não usa. Principalmente em servidores. Isso vai tornar suas máquinas mais seguras e vai tornar mais fácil para você manter tudo atualizado.

Assine a companhe os boletins de segurança dos softwares que você usa. Você não quer correr o risco de não ficar sabendo de uma atualização crítica e ter seu sistema vulnerável simplesmente por não ter sido avisado, não é?

Por fim, é importante que você saiba que a essa falha de segurança no Samba é especialmente preocupante porque muitos dispositivos NAS e outras soluções de armazenamento de dados usam Samba. Então se você possui um equipamento de armazenamento de dados, é bom investigar se ele usa Samba e está vulnerável a essa falha.

PS: obrigado ao Rodrigo por me avisar.

O post Mantenha seus servidores enxutos apareceu primeiro em Elcio Ferreira.

sudo apt-get install colordiff kbtin

Agora você pode:

diff arquivo1.txt arquivo2.txt | colordiff | ansi2html > diff.html

Ou, com git:

git diff | colordiff | ansi2html > gitdiff.html

Você também pode salvar a saída de qualquer comando que retorne ANSI colorido:

ls -lha --color | ansi2html > ls.html

O post Salvando diff em HTML apareceu primeiro em Elcio Ferreira.

ps aux|grep root

Quase tudo em Linux é representado como arquivos. As informações sobre os processos rodando estão em arquivos virtuais dentro de /proc. Você pode remontar /proc, passando uma opção para controlar a visibilidade dos processos, assim:

sudo mount -o remount,rw,hidepid=2 /proc

Em seguida, tente novamente:

ps aux|grep root

Você vai ver que os usuários, com hidepid=2, não poderão ver processos de outros usuários. Para desfazer, execute:

sudo mount -o remount,rw,hidepid=0 /proc

Assim, você pode configurar seu servidor para que um usuário não possa saber o que os outros estão fazendo.

O post Escondendo processos dos outros usuários apareceu primeiro em Elcio Ferreira.

Numa tela simples de terminal temos uso de memória, CPU, rede, I/O e espaço em disco. Aperte h para ver a ajuda.

Para instalar:

sudo apt-get install glances

E para executar:

sudo glances

Claro, se você não usa Debian/Ubuntu, troque apt-get por yum, pacman, emerge ou o comando correspondente em sua distro.

O post Para onde foi a performance do seu Linux? Glances nele! apareceu primeiro em Elcio Ferreira.

Então rode o python e se divirta:

import this
import __hello__
from __future__ import braces
import antigravity

E uns outros que eu acho interessantes:

No vim, tente:

:help 42
:help holy-grail
:help UserGettingBored
:help!
:Ni!

Esses agora, são apenas para Debian, Ubuntu e derivados. Tente isso e dê uma olhada na última linha:

apt-get help

Depois tente:

apt-get moo

E depois de ter visto esses dois do apt, esse aqui vai fazer um bocado de sentido:

aptitude help
aptitude moo
aptitude -v moo
aptitude -vv moo
aptitude -vvv moo
aptitude -vvvv moo
aptitude -vvvvv moo
aptitude -vvvvvv moo

E o último dessa série (talvez você precise instalar o apt-build para ver):

apt-build moo

Se você é um administrador de servidor, pode deixar um easter egg para seus usuários sudoers. Rode:

sudo visudo

E inclua, no bloco de configurações começando com “Defaults”, a seguinte linha:

Defaults insults

Salve e saia. Agora, quando um usuário sudoer errar a senha, o sudo vai insultá-lo em retribuição.

Esses próximos estão na internet, mas devem ser aproveitados num terminal:

telnet towel.blinkenlights.nl
traceroute -m 254 -q1 obiwan.scrye.net

É isso. Conhece mais? Deixe aí nos comentários.

O post Easter eggs no Python e um pouco mais apareceu primeiro em Elcio Ferreira.

sudo apt-get install curl mpg123

Depois crie o script falador:

#!/bin/bash
l=pt-BR
if [ "$1" == "-l" ];then
  shift
  l=$1
  shift
fi
curl -A "Falador" translate\.google\.com/translate_tts -d "tl=$l&ie=UTF-8&q=$@" |mpg123 -;

Dê permissão de execução:

chmod +x falador

E divirta-se:

./falador "Onde está o futuro que nos prometeram?"
./falador -l en "Luke, I am your father."

O post Faça o Google falar por você apareceu primeiro em Elcio Ferreira.

DROP TRIGGER IF EXISTS impededelete;
DELIMITER $$
CREATE TRIGGER impededelete BEFORE DELETE ON transacao
FOR EACH ROW BEGIN
  SIGNAL sqlstate '45001' set message_text = 'Bloqueado.';
END;
$$
DELIMITER ;

Pronto.

O post Trigger para impedir exclusão de registro no MySQL apareceu primeiro em Elcio Ferreira.

DURAÇÃO: 2h

Aprenda os fundamentos do terminal do Linux, domine os comandos mais comuns mas, além disso, aprenda um novo jeito de pensar. Automatize tarefas e coloque seu computador para trabalhar por você.

Por que estamos oferecendo esse curso?

Durante os últimos anos eu tenho ensinado milhares de técnicos, programadores e webdesigners a ser mais produtivos. Treinei equipes inteiras de empresas como iG, Terra, Yahoo!, Locaweb, Magazine Luíza e Editora Abril. Além disso, tenho sido chamado para palestrar em grandes eventos técnicos em todas as regiões do Brasil.

Mas sinto que o Brasil (e provavelmente o mundo) tem uma carência enorme de conhecimento em computação. E essa carência não poderá ser preenchida apenas ensinando mais a quem já é especialista no assunto. Por isso, fiquei muito feliz quando o Maudy, do Ubuntu Dicas, me convidou para ensinar os segredos do terminal do Linux a iniciantes. E o resultado disso é esse curso que você poderá assistir hoje, quinta-feira, dia 30, às 20h.

Temos sentido, tanto na comunidade Ubuntu Dicas quanto no mercado em geral, um grande interesse dos usuários iniciantes em aprender os segredos do terminal do Linux. É uma ferramenta fantástica de automatização de tarefas, capaz de fazer seu computador trabalhar por você. E também é a porta de entrada para uma série de novos conhecimentos e, inclusive, para um novo jeito de pensar.

Por que você deve dominar o terminal?

Eu comecei minha carreira como programador Windows. Como todo usuário experiente de Windows, eu dominava uma porção de truques avançados do próprio Windows e de seus programas. Foi nessa época que comecei a estudar Linux. Um dia meu chefe na época apareceu com uma tarefa desafiadora para mim. Todos os dias chegava, no mesmo horário, um CD com imagens vindas das filiais. Sim, em CD, naquela época fazer esse tipo de coisa pela Internet ainda era muito lento. E essas imagens deviam ser preparadas para publicação no site. Não era uma tarefa complexa, precisava basicamente redimensionar as imagens e copiá-las para a pasta certa através de um programa de FTP.

Eu resolvi o problema usando um recurso do Photoshop para processamento em lote, chamado “batch” na versão em inglês. Criei uma action no Photoshop para ser executada com o recurso de batch e, todos os dias, quando o CD chegava, eu copiava o conteúdo para uma determinada pasta, abria o Photoshop, executava o processamento em lote e aguardava o Photoshop terminar. Ao final, abria um programa de FTP e copiava os arquivos para o servidor do site.

Era uma tarefa enfadonha, repetitiva e aquilo começou a me deixar desanimado. Eu passava as tardes me sentindo mal, antecipando o momento em que eu teria que parar meu trabalho para copiar as imagens e ficar olhando o Photoshop trabalhar.

Felizmente, foi nessa época que eu comecei a aprender Linux. E com um bocado de estudo e um pouco de esforço cheguei a uma sequência de comandos que resolvia o problema:

cd imagens_filiais/entrada
for i in *.jpg;do  
  convert -thumbnail 300x300 $i $i
done
mv entrada `date +%Y%m%d`
cd ..
rsync -razv . servidor:imagens_filiais/

Uma simples sequência de sete linhas. Claro, você pode achar esses comandos assustadores, e pensar que dá mais trabalho digitar isso tudo do que simplesmente copiar a pasta, renomear, executar a action no Photoshop, abrir o programa de FTP e copiar os arquivos. Acontece que só foi necessário digitar esses comandos uma vez. Criei um arquivo com essa sequência de comandos e, cada vez que o CD de imagens chegava, eu copiava as imagens para a pasta entrada e executava um único comando. Consegue imaginar meu alívio e alegria ao conseguir me livrar dessa tarefa repetitiva, colocando o computador para trabalhar para mim?

Não se assuste com os comandos. Eu também tinha medo deles e não entendia nada quando os vi pela primeira vez. Mas eles são simples, acredite. Muito simples. Se você entender os conceitos fundamentais, vai entender esses comandos e qualquer outro com que tiver que lidar, com facilidade. E é fácil entender, você vai ver.

Você vai gastar duas horas estudando hoje e com certeza, vai economizar muito mais do que duas horas na primeira tarefa repetitiva que chegar às suas mãos. E vai parar de ter medo do terminal.

Por que você deveria se inscrever para esse curso agora?

Por que o curso, com interação ao vivo, vai estar disponível apenas hoje, dia 30/01. Além disso quem se inscrever até lá vai receber também a apostila do treinamento e um bônus especial, preparado com carinho para quem quer avançar na automatização de tarefas. Esta é então uma chance única, uma oferta que não estará disponível depois de quinta-feira. Depois disso você poderá adquirir apenas o acesso à gravação do curso. A apostila estará disponível exclusivamente para quem adquirir o acesso até às 20h.

Nós temos tanta certeza que você vai gostar do curso que, para que você tenha certeza ao se inscrever, oferecemos a exclusiva garantia completa: se você assistir o treinamento ao vivo e, por qualquer motivo, não estiver satisfeito com o que aprendeu, você pode simplesmente escrever para a gente e obter seu dinheiro de volta. Todo o seu dinheiro de volta, sem letras miúdas, sem perguntas, basta mandar um e-mail.

Para quem é esse curso?

Se seu trabalho envolve lidar com arquivos em um computador e realizar tarefas que podem ser automatizadas, esse curso é para você. Se você apenas navega na internet, escreve textos e planilhas, por favor, não se inscreva. Mas se você precisa lidar com tarefas como capturar dados da internet, lidar com arquivos em grandes volumes, tratar texto, imagens, vídeos ou áudio, administrar servidores ou qualquer outra tarefa repetitiva que possa ser automatizada, você PRECISA fazer esse curso.
Eu tenho certeza que, se você trabalha assim com um computador, vai recuperar o tempo investido em estudar em no máximo uma semana.

Inscreva-se

Elcio Ferreira é sócio-diretor da Visie Padrões Web, empresa especializada no desenvolvimento de sites, sistemas web e aplicativos móveis. Já treinou e auxiliou equipes de desenvolvimento de centenas de equipes em empresas como Globo.com, Editora Abril, iG e Terra. Trabalhando com web há mais de quinze anos, Elcio é nome de referência no Brasil em padrões web e tecnologias abertas para a internet, sendo membro do grupo de trabalho de acessibilidade do W3C. Durante o ano de 2011, ministrou os treinamentos oficiais de HTML5 na sede do W3C Brasil.

O post Mini-curso dominando o terminal do linux apareceu primeiro em Elcio Ferreira.

Você sabia que pode enviar um arquivo para a lixeira a partir do terminal, ao invés de apagá-lo? Para isso, você precisa instalar o pacote trash-cli. No Ubuntu, faça:

sudo apt-get install trash-cli

Em seguida você pode usar, no lugar do comando rm, o comando trash:

trash arquivo_a_apagar.txt

Você também pode manipular a lixeira com os comandos trash-list, restore-trash e trash-empty.

Substituindo o comando rm

E se quiser você evitar usar o comando rm por engano, insira no final de seu .bashrc:

alias rm=trash

Assim, cada vez que você digitar o comando rm, será na verdade executado o comando trash. E se você deliberadamente quiser excluir um arquivo, sempre poderá chamar o comando rm digitando uma contrabarra, assim:

\rm arquivo_a_apagar.txt

Mas você tem certeza que vai substituir o comando rm?

Na página do trash-cli o autor trata dessa questão. Ele diz que, embora você possa substituir o comando  rm pelo trash, você não deveria, porque os argumentos dos dois comandos são diferentes. Por exemplo, o comando rm exige o argumento -R para remover diretórios, o trash não. Então ele sugere que não o faça.

Mas, se você tem medo de apagar arquivos por engano, ele sugere uma outra abordagem. Crie um alias para o comando rm em seu .bashrc assim:

alias rm='echo "Este não é o comando que você quer executar."; false'

E pronto, você não vai mais executar o comando rm por engano, mas, do mesmo modo que no primeiro exemplo, sempre poderá executá-lo deliberadamente, começando com uma contrabarra.

PS1: o trash-cli é feito em Python, e muito bem escrito. Estudar o código dele pode ser muito instrutivo.

PS2: estou prestes a lançar, junto com o Ubuntu Dicas, uma novidade para quem quer aprender a usar o terminal. Se você é iniciante no terminal do Linux e gostaria de aprender os segredos para dominar o terminal, você precisa assinar a lista do Ubuntu Dicas.

O post Fazendo o comando rm enviar arquivos para a Lixeira apareceu primeiro em Elcio Ferreira.

Há um tempo eu li “The Pragmatic Programmer“, uma espécie de livro de auto-ajuda para programadores. Não é um livro técnico, não vai te ensinar técnicas ou tecnologias, mas fala de um jeito de pensar e traz uma coleção de conselhos daquele tipo que parece óbvio mas ninguém nunca faz.

Um desses conselhos era aprender novas linguagens de programação. Os autores recomendam que você se torne proficiente em uma nova linguagem de programação por ano. O que, eu sei, é muito difícil. Eu não tenho conseguido aprender uma nova linguagem por ano. Mas isso não invalida o conselho de que você deve aprender novas linguagens de programação.

Por que aprender linguagens de programação novas?

Cada linguagem de programação traz consigo um jeito de pensar, um conjunto de soluções e uma comunidade com cultura diferente. E isso enriquece você. O bom programador tem uma visão ampla e não está “preso” a uma única tecnologia.

Por exemplo, digamos que você esteja desenvolvendo um sistema em PHP e precise, de tempos em tempos, fazer parsing de feeds RSS cuja URL foi cadastrada pelos usuários. Digamos que você queira fazer o parsing em segundo plano, a cada meia hora. Claro, você pode usar SimplePie, mas ele não é tão “Simple” assim. Dê uma olhada na documentação. SimplePie é muito poderoso, tem uma porção de recursos, mas vai dar algum trabalho para instalar direito, montar seu script, testar e automatizar.

E se você procurar soluções em outras linguagens de programação? Quanto trabalho vai ter? Vamos ver o que Python tem para nós, usando o excelente módulo feedparser. O módulo feedparser está disponível no gerenciador de pacotes do Ubuntu, e também para instalação via PIP.

import feedparser
print feedparser.parse('https://elcio.com.br/feed')

Mais uma meia dúzia de linhas para ler as URLs e salvar os resultados no banco de dados e pronto, temos um arquivo simples com excelente performance para ser colocado no cron. Bom, falando em performance, esse é o típico processamento que vai rodar muito mais rápido se feito em paralelo. Processamento em paralelo com PHP é um parto, certo? Com Python você pode usar o módulo multiprocessing e fazer isso quase que em uma linha só.

Além de ferramentas, linguagens de programação carregam jeitos de pensar

Uma vez que você já tenha resolvido um problema em uma linguagem de programação, você consegue resolver o mesmo problema em qualquer outra, certo? Bom, quando você aprende uma linguagem nova, você acaba tendo que ler um bocado de código de outras pessoas. E isso te ensina novas soluções para os seus velhos problemas.

Isso é diferente de se aprofundar no estudo de sua linguagem atual. O aprofundamento vai fazer você ler mais códigos das mesmas pessoas, da mesma comunidade, da mesma cultura. Aprender uma linguagem nova faz você ler códigos de gente nova, com outra cultura. Na prática, aprender Python vai fazer você melhor programador PHP, aprender Smalltalk vai fazer você melhor programador Java, etc.

Porque Python

De todas as linguagens de programação que você poderia escolher para começar a aprender algo novo hoje, eu recomendo que, se você ainda não sabe Python, comece por ela. Python roda no Google App Engine, no AWS Elastic Beanstalk e é a linguagem de programação por trás da maioria das ferramentas de administração do Ubuntu. Se você quer construir pequenos scripts para automatizar tarefas em seu servidor, ou quer construir grandes aplicações web para rodar em Cloud, ou se quer criar ferramentas de processamento paralelo massivo, ou interfaces gráficas multiplataforma, Python vai servir.

E é, ao mesmo tempo, uma linguagem que possui recurso fantásticos e vai te ensinar coisas incríveis, e uma das linguagens mais fáceis de aprender que eu conheço.

Que tal começar agora? Leia o excelente “Dive Into Python“, faça os exercícios, depois tente desenvolver alguma coisa na linguagem. E veja se você não vai se tornar mais eficiente em sua linguagem atual.

“Jabá”: Python é a linguagem que escolhemos para a aula de integração multi-linguagem do DevOps Heroes, treinamento da Visie que acontece a partir do dia 27 em São Paulo. Quem estiver lá vai ver isso tudo funcionando na prática. As vagas estão se esgotando.

O post Porque você deveria aprender várias linguagens de programação apareceu primeiro em Elcio Ferreira.

Por que você não deveria usar FTP

FTP é um protocolo muito simples de troca de arquivos, que pode ser útil para uma porção de coisas. Mas não possui os recursos necessários para o deploy e controle eficiente de aplicações web. Entre os problemas com o protocolo FTP, podemos citar:

1. Falta de integração com controle de versão: você está fazendo uma manutenção num site, cujo diretório tem 5MB de dados. Você alterou não mais que uma dúzia de arquivos, em pastas diferentes. Arquivos texto cujos tamanhos, somados, não passam de 200KB. Como você faz o deploy por FTP? Ou sobe o site todo, “por via das dúvidas”, ou precisa pinçar os arquivos que precisa subir, um a um, certo? Algumas ferramentas de transferência, como o Filezilla, conseguem “sincronizar” as pastas, mas eles fazem isso varrendo as pastas uma por uma e comparando as datas e tamanhos dos arquivos. Leva um tempão e, se algum outro programador alterou os arquivos antes de você isso certamente vai dar problemas. O que nos leva a um segundo ponto:
2. Falta de recursos de “auditoria” e controle de deploys: não há como obter um log ou lista de quem fez deploy, quando e o que foi feito. Um problema recorrente em ambientes em que uma equipe trabalha com FTP é a sobrescrita de alterações já publicadas. Na pior das hipóteses, gerando perda de trabalho. Mas mesmo que a equipe tenha um ambiente interno de controle de versões e a sobrescrita no FTP seja fácil de resolver, pense na dor de cabeça de ter que explicar para o cliente que o defeito que foi corrigido ontem voltou ao ar hoje, mas já estamos resolvendo.
3. Falta de automatização: deploy por FTP é feito à mão. Um homo sapiens navega nas pastas de seu computador e do servidor e arrasta o que deve ser atualizado de um lado para outro. Num processo chato e delicado. Se ele arrasta as coisas para a pasta errada, pode ser muito difícil consertar o problema. Pode ser difícil até entender o problema. E se você coloca um homo sapiens para repetir uma mesma tarefa vinte ou trinta vezes, ele certamente vai errar alguma.
4. Falta de recursos para rollback automatizado: você subiu a alteração. Em seguida abriu o site e viu um “erro de conexão ao banco de dados”. Percebe então que subiu a versão errada, ou no lugar errado. Como voltar atrás? Voltar atrás com FTP é um processo ainda mais manual e trabalhoso do que subir o site. Já vi casos, e não foram poucos, em que foi preciso pedir ao provedor para restaurar o backup diário. E esperar por isso, claro.

O que você deveria usar então?

SSH e Git. Há uma série de ferramentas para deploy automático, como o Capistrano ou o Jenkins. Esqueça isso tudo no começo. Aprenda SSH e Git, e construa seu processo de deploy com isso. Você vai ganhar:

1. Deploy realmente automático. Com um único comando.
2. Integração real com o controle de versão. Isso significa que sempre será possível rastrear cada alteração. Também significa rollback automático, o que é maravilhoso.
3. Controle simplificado de múltiplos ambientes. Precisa fazer deploy em um ambiente de homologação, para mostrar as novidades ao cliente? Um comando. Ele aprovou as novidades, e agora é hora de fazer deploy em produção da versão que foi homologada ontem? Um comando.
4. Preparação para o futuro. O site cresceu e você precisa agora migrar para um serviço como o AWS Elastic Beanstalk, que oferece escalabilidade “elástica” sob demanda dentro da estrutura de serviços da Amazon. O processo vai ser praticamente indolor. O cliente precisa agora de deploys com zero de indisponibilidade, e você resolveu usar a estratégia Blue Green. Já tem tudo o que precisa.

Por isso, não se conforme em usar FTP. Se precisa estudar SSH e Git, estude, vai valer a pena. Se já sabe, está esperando o quê?

“Jabá”: uma boa maneira de aprender como mudar seus processos de deploy, e muito mais, é o treinamento DevOps Heroes da Visie, que acontece daqui a duas semanas.

O post Pare de usar FTP apareceu primeiro em Elcio Ferreira.

import webbrowser
webbrowser.open("http://visie.com.br")

E o site da Visie será aberto no navegador do usuário. Muito útil se você está fazendo um programa para desktop ou mesmo um script para o terminal. No caso de scripts para terminal, se o usuário estiver rodando o script sob uma interface gráfica o site será aberto no navegador padrão dele, já se estiver rodando via ssh ou num outro terminal sem interface gráfica, será usado um navegador de CLI (como o Lynx) se estiver disponível.

O post Pequena dica de Python: módulo webbrowser apareceu primeiro em Elcio Ferreira.

O post Python from Humans apareceu primeiro em Elcio Ferreira.

sudo apt-get install cowsay

Depois rode:

cowsay Funciona...

O cowsay também pode receber texto na entrada padrão:

date|cowsay

Isso permite usos razoavelmente criativos:

lynx --dump http://news.google.com.br | grep "^\[" | grep -v "»" \
| sed -e "s/.*\]//g" | sort -R | head -n 1|cowsay

Você pode colocar seu Ubuntu para te dar uma dica de Linux toda vez que você abre o terminal, assim:

sudo apt-get install fortunes-ubuntu-server

Depois edite o arquivo ~/.bashrc e inclua no final:

fortune|cowsay

E pronto! Cada vez que você abrir um terminal vai receber uma dica de Ubuntu.

O post Cowsay: a vaquinha falante do Linux apareceu primeiro em Elcio Ferreira.

Veja como descobrir onde estão os fontes de um módulo qualquer:

>>> import glob
>>> glob.__file__
'/usr/lib/python2.7/glob.pyc'

O nome do arquivo tem a extensão pyc. É um compilado. Tire o último “c” e você terá o caminho do arquivo com o código fonte. Dê uma lida no conteúdo do glob.py, por exemplo, e você deve achar muito simples mas bastante interessante.

Se você está aprendendo Python agora, sempre que for resolver uma tarefa sobre determinado assunto, dê uma olhada no código dos módulos relacionados aquele assunto. Você vai ver como a comunidade Python tem abordado problemas semelhantes aos seus e com certeza vai aprender muito.

O post Pequena dica de Python: leia os fontes apareceu primeiro em Elcio Ferreira.

$ sudo apt-get install cclive

E para usar:

$ cclive http://www.youtube.com/watch?v=8fvTxv46ano

Isso vai baixar o vídeo na pasta atual. Simples e indolor. Mas qual a vantagem de usar a linha de comando em relação a uma extensão no navegador, onde você não precisa digitar comandos? Com a linha de comando é possível automatizar as tarefas. Criei um script que recebe um nome de usuário do YouTube e baixa os últimos 15 vídeos publicados. Chamei o arquivo de massclive. Veja o código fonte:

mkdir -p $1

lynx --dump http://www.youtube.com/user/$1/feed | \
  grep youtube.com/watch | \
  sed -e "s/.* //" | \
  sed -e "s/&.*//" | \
  sort -u | \
  while read url
  do
    cclive -c --output-dir $1 $url
  done

E você pode usar assim:

$ ./massclive maninthearenatv

O post Pacote Ubuntu: cclive apareceu primeiro em Elcio Ferreira.