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.

Então vamos lá: nossos computadores são muito potentes hoje em dia. Muito. Dificilmente mudar a lógica de um cálculo, criar uma variável a menos, otimizar um loop, ou até concatenar menos strings vai fazer algum diferença sensível. Então, não pré-otimize, não otimize antes de medir.

Vamos mostrar um exemplo. Fiz em Python só porque eu gosto, mas a mesma coisa vale para sua linguagem favorita. Escrevi os dois arquivos a seguir:

strings1.py

tamanho=20
a='a'
for i in range(tamanho):
    a*=2
print(len(a))

strings2.py

tamanho=20
a='a' * (2**tamanho)
print(len(a))

São duas maneiras bem diferentes de se criar uma grande string. A segunda é muito mais eficiente que a primeira. Bom, veja os resultados da execução aqui na minha máquina:

$ time python strings1.py
1048576
real 0m0.023s
user 0m0.013s
sys 0m0.008s
$ time python strings2.py
1048576
real 0m0.021s
user 0m0.012s
sys 0m0.008s

Nenhuma diferença prática, certo? Aumentei a variável tamanho para 30, agora notamos diferença:

$ time python strings1.py
1073741824
real 0m1.375s
user 0m0.671s
sys  0m0.691s
$ time python strings2.py
1073741824
real 0m0.586s
user 0m0.235s
sys  0m0.344s

Agora a diferença é absurda, certo? Mas quando foi a última vez que você precisou concatenar strings de um bilhão de caracteres? O caso é: se suas strings vão chegar a esse tamanho, você provavelmente vai saber disso antes. Por exemplo, se você está fazendo um software de tratamento de imagens, parece óbvio que processamento pode ser um problema, certo? Se não, gastar seu tempo e esforço com otimização de performance provavelmente não vale a pena.

Aviso: o código do exemplo 1 é muito ruim, além de dar mais trabalho para escrever. Eu não estou sugerindo que você escreva código ruim de propósito, tá? Apenas que você não se preocupe demais com performance e não gaste seu tempo resolvendo problemas imaginários.

Há, porém, algumas situações em que tudo o que eu disse acima não vale. Nossos processadores são muito rápidos, nossas memórias também. Discos já não são tão rápidos assim. Bancos de dados, mais ou menos. A internet, bom, quem pode confiar na internet, né?

Então, se você vai consumir um webservice, e pode mudar seu algoritmo para fazer dez chamados ao invés de vinte, faça isso. Se vai escrever muito no disco, e puder reduzir em 20% as operações de escrita de arquivos, faça isso. Se escrevendo uma consulta SQL mais complexa você consegue fazer muito menos consultas ao banco de dados e usar mais índices, faça isso.

Eu faço mais ou menos assim em relação a performance:

1. Vamos usar a internet? Otimize sempre.
2. Vamos gravar grandes arquivos, ou fazer uso intensivo de disco? Otimize sempre.
3. Cálculo científico, tratamento de imagens e outras operações de processamento massivo? Otimize sempre.
4. Bancos de dados com milhões de registros e uso intenso? Otimize sempre.
5. Uso comum de arquivos e bancos de dados? Cuide de não escrever nada muito ruim, e otimize se der problema.
6. O resto todo? Escreva pensando em legibilidade, encapsulamento e reuso. Só otimize se tiver problemas.

Publiquei um vídeo sobre isso há um tempo, se você quiser dar uma olhada: Não pré-otimize.

O post Otimização de performance prematura: não faça! apareceu primeiro em Elcio Ferreira.

Afinal, calcular a média de uma lista é uma necessidade comum, certo? Deve haver no Python algum jeito fácil de fazer, então. Quando eu disse que não, meu amigo gastou alguns segundos pesquisando e chegou nessa solução:

import numpy
l = [ 2, 5, 6.8, 9, 7]
avg = numpy.mean(l)

Funciona. Não é muito código. Mas tem alguns problemas:

1. Cria uma dependência extra: será preciso ter o numpy instalado para que a aplicação funcione
2. Complica um pouco mais o código: nem todo mundo sabe o que faz o método .mean(), fazendo com que outros programadores tenham que gastar um tempinho pesquisando
3. Tem uma performance pior: ou, pelo menos, para os tamanhos de lista mais comum. A função de média do numpy é otimizada. Deveria portanto, ser mais rápida. Se você tiver que calcular centenas de médias de listas gigantescas, numpy vai fazer diferença. Mas não é o caso da maioria das aplicações. Se você for usar pouco a função mean() o custo de importá-la é maior que o de fazer o cálculo você mesmo.

E como fica esse cálculo? O jeito como eu recomendo calcular a média de uma lista em Python é esse:

l = [ 2, 5, 6.8, 9, 7]
avg = sum(l)/len(l)

A dica é: antes de procurar ou construir um módulo com a solução do seu problema, pense se não é um problema simples demais para isso. Se você fizer esse exercício, vai evitar escrever código como esse:

import calculations
x = calculations.sum(2, 7)

Ao invés de:

x = 2 + 7

E não, não tem filosofia, técnica ou estratégia que você posa usar para tentar me convencer de que o primeiro jeito é melhor do que o segundo.

O post Média de lista em Python, como calcular apareceu primeiro em Elcio Ferreira.

1. Atribuição múltipla (com tuple unpacking)

a, b, c = 1, 2, 3

2. Com isso dá para trocar o valor de variáveis

a, b = b, a

3. Encadeamento de comparadores

x = 3
print(1 < x < 5) # True

4. Generators

def fib(max):
    n1, n2 = 0, 1
    for i in range(max):
        yield n1
        n1, n2 = n2, n1 + n2
f = fib(20)
for i in f:
    print(i)

5. If em uma linha

aliquota = 0.05 if valor < 1000 else 0.07

6. List comprehension

# Quadrados dos números de 0 a 99
[i ** 2 for i in range(100)]

# Quadrados dos números de 0 a 99, apenas
# se o resultado não contém o dígito "4"
[i ** 2 for i in range(100) if not '4' in str(i**2)]

7. Invertendo uma string

a = a[::-1]

8. enumerate

for i, l in enumerate('palavra'):
    print (i, l, end=' / ')
# 0 p / 1 a / 2 l / 3 a / 4 v / 5 r / 6 a /

9. Unpacking estendido (só Python 3)

a, *b, c = "unpacking"
print(a, b, c)
# u ['n', 'p', 'a', 'c', 'k', 'i', 'n'] g

10. Dict comprehension

d = {i: i**2 for i in range(10)}
print(d)
# {0: 0, 1: 1, 2: 4, 3: 9, 4: 16, 5: 25, 6: 36}

11. String formatting

dados={'nome': 'Joaquim', 'email': 'jsilva@fbi.gov'}
print('%(nome)s <%(email)s>' % dados)
# Joaquim <jsilva@fbi.gov>
print('{nome} <{email}>'.format(**dados))
# Joaquim <jsilva@fbi.gov>

12. zip

list(zip([1, 2, 3], [4, 5, 6]))
[(1, 4), (2, 5), (3, 6)]

Módulos Úteis

1. collections

import collections
print(collections.Counter('banana'))
# Counter({'a': 3, 'n': 2, 'b': 1})
d = collections.defaultdict(lambda:'...')
d['nome'] = 'Teste'
print(d['nome']) # Teste
print(d['idade']) # ...

2. pprint

from pprint import pprint
pprint(['a' * i for i in range(20)])
# ['',
#  'a',
#  'aa',
#  'aaa',
#  'aaaa',
#  'aaaaa',
#  'aaaaaa',
#  'aaaaaaa',
#  'aaaaaaaa',
#  'aaaaaaaaa',
#  'aaaaaaaaaa',
#  'aaaaaaaaaaa',
#  'aaaaaaaaaaaa',
#  'aaaaaaaaaaaaa',
#  'aaaaaaaaaaaaaa',
#  'aaaaaaaaaaaaaaa',
#  'aaaaaaaaaaaaaaaa',
#  'aaaaaaaaaaaaaaaaa',
#  'aaaaaaaaaaaaaaaaaa',
#  'aaaaaaaaaaaaaaaaaaa']

3. itertools

import itertools
for i in itertools.permutations("123"):
    print("".join(i), end=", ")
# 123, 132, 213, 231, 312, 321,
for i in itertools.product("01", repeat=3):
    print("".join(i), end=", ")
# 000, 001, 010, 011, 100, 101, 110, 111,

4. SimpleHTTPServer

➜  ~ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

5. webbrowser

import webbrowser
webbrowser.open('https://campus.visie.com.br/')

6. atexit

➜  ~ python3 -q
>>> def teste():
...     print('Bye!')
...
>>> import atexit
>>> atexit.register(teste)
<function teste at 0x10973a620>
>>> ^D
Bye!
➜  ~ _

7. base64

import base64
print(base64.b64encode(b'Teste'))
# b'VGVzdGU='

8. gzip

import gzip
print(gzip.open('teste.txt.gz').read())

Easter Eggs

Tente aí:

>> import this
>> import hello
>> import antigravity
>> from __future__ import braces

O post Recursos “escondidos” do Python 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.

O problema? Muitas vezes, otimizar seu texto para uma determinada palavra-chave o torna chato de ler. Seu texto fica mais ou menos assim:

… Ao usar um plugin de SEO para WordPress, você corre o risco de escrever um texto mecânico. É verdade que plugins de SEO para WordPress são uma coisa boa, mas você precisa tomar cuidado para não deixar seu plugin de SEO para WordPress mandar em você…

Você quer apenas ser encontrado? Tem um monte de sites por aí tão cheios de publicidade que tornam quase impossível ler o que está escrito. O objetivo é ser encontrado e gerar um clique patrocinado, apenas isso. Se é isso o que você está construindo, vá em frente, siga as regras do plugin e você vai poupar um bocado de tempo.

Mas se seu objetivo é que as pessoas encontrem, leiam e entendam o que você está escrevendo, então seguir cegamente as regras não é a melhor decisão.

Escreve para pessoas, depois faça o que for possível para agradar os robôs.

Há um tempo que eu tenho usado o Pylint em alguns projetos. Ele me avisa se eu deixo de seguir algum padrão de código. Ele até dá uma nota para o meu código!

Mas o recurso mais legal do Pylint é poder fazer isso:

import config # pylint: disable = relative-import

Ou seja, não preciso seguir as regras cegamente.

Você também pode decidir quando quebrar as regras. Escolha com cuidado.

O post Não seja escravo das suas ferramentas apareceu primeiro em Elcio Ferreira.

Às vezes isso é bom. Veja como ler um arquivo texto em Java:

import java.io.*; 
public class ReadingFromFile 
{ 
    public static void main(String[] args) throws Exception 
    { 
	FileReader fr = 
	new FileReader("arquivo.txt"); 

	int i; 
	while ((i=fr.read()) != -1) 
	    System.out.print((char) i); 
    } 
} 

Agora compare com a mesma coisa em Python:

print(open('arquivo.txt').read())

Nesse caso, parece óbvio que a resposta em Python é muito melhor, não? Agora olhe esse código em JavaScript:

urlscore = url.indexOf('http') ? -1 : (url.indexOf('https://')+1)*5 + 
                                      (url.split('/')[2].indexOf('www')?1:0)*2 + 
                                      (url.split('/')[1].indexOf('@')>-1?-1:1)*3

Uau! O sujeito reduziu a função inteira a uma única expressão! Parece uma boa ideia pra você? Coitado de quem tiver que dar manutenção nisso!

Seu inimigo não é a quantidade de código, é a complexidade. É difícil dar uma boa definição técnica de complexidade, mas você a reconhece quando vê.

O post Não é sobre quantas linhas de código você escreve apareceu primeiro em Elcio Ferreira.

É por isso que padrões e convenções são uma ideia tão boa.

Quanto tempo você já passou olhando o código de alguma aplicação, tentando descobrir onde estão as coisas? No web2py, um dos meus frameworks favoritos, quando você cria uma nova aplicação, a pasta de código se parece com isso:

Web2py é um framework MVC, que, você sabe, é a sigla para model, view e controller. Para acessar o banco de dados você escreve um model. E como se chama a pasta onde estão seus models? Ok, models. E as regras de negócio devem ir num controller. E onde estão seus controllers? Na pasta controllers, claro. E as views na pasta views.

Zero esforço para entender, zero esforço para decorar.

Eu sei que é bem pouco esforço decorar que, no seu novo framework da moda, as views estão dentro de /presentation/templates/html, os controllers em /app/core/controllers e os modelos em /persistence/rdbs. Mas pouco é infinitamente mais do que zero. E, acredite, esses pequenos esforços, somados, fazem um bocado de diferença.

O post Quanto mais óbvio, melhor apareceu primeiro em Elcio Ferreira.

Era mais fácil fazer com shell script, é verdade, mas eu precisava que fosse multiplataforma.

O post Conversor recursivo de charset apareceu primeiro em Elcio Ferreira.

Você pode instalar via pip com:

pip install requests

Depois, veja como é fácil:

>>> import requests
>>> r=requests.get('http://visie.com.br')
>>> for k,v in r.headers.iteritems():print k,'=>',v
... 
content-length => 7669
content-encoding => gzip
accept-ranges => bytes
expires => Mon, 20 Jan 2014 13:18:30 GMT
vary => Accept-Encoding,Cookie
server => Apache
last-modified => Mon, 20 Jan 2014 12:38:24 GMT
cache-control => max-age=3, must-revalidate
date => Mon, 20 Jan 2014 13:18:27 GMT
content-type => text/html; charset=UTF-8
>>> r.status_code
200
>>> r.reason
'OK'
>>> r.content[:15]
'<!DOCTYPE html>'

Se você precisar fazer uma requisição HTTPS com autenticação e obter o retorno em JSON:

>>> r=requests.get('https://httpbin.org/basic-auth/user/passwd',auth=('user','passwd'))
>>> r.json()
{u'authenticated': True, u'user': u'user'}

Para fazer POST:

>>> r=requests.post('https://httpbin.org/post',data={'foo':'bar'})
>>> r.json()['form']
{u'foo': u'bar'}

Tudo muito, muito simples. E o módulo faz muito mais e está muito bem documentado. Olhe lá.

O post Módulo Python: requests 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.

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.

Críticas, sugestões e, claro, pull requests são muito bem-vindos!

O post Visualdal, modelagem de dados visual e web2py apareceu primeiro em Elcio Ferreira.

>>> class Class:
...   def um(self):
...     return 1
... 
>>> c=Class()
>>> c.um()
1
>>> def dois(self):
...   return 2
... 
>>> Class.dois=dois
>>> c.dois()
2
>>> Class.tres=lambda self:3
>>> c.tres()
3
>>> Class.um=lambda self:'Um modificado.'
>>> c.um()
'Um modificado.'

As classes em Python são completamente dinâmicas. Você pode acrescentar métodos quando quiser e isso se refletirá em todos os objetos criados com aquela classe (mais ou menos como o que você faz em Javascript com prototype.)

O post Pequena dica de Python: as classes são dinâmicas 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.

# -*- encoding: utf-8 -*-
import string,random

template='''Sugestões para %(nome)s:
 - login: %(login)s
 - email: %(email)s
 - site: www.%(domain)s.com
 - senha: %(passwd)s
'''

def sugere_logins(nome):
    login=nome.split(' ')[0].lower()
    domain=nome.split(' ')[-1].lower()
    email=login+'@'+domain+'.com'
    chars=string.letters+string.digits
    passwd=''.join(random.sample(chars,10))
    dados={'login':login,
           'email':email,
           'nome':nome,
           'domain':domain,
           'passwd':passwd}
    print template % dados

Você pode substituir todo o trecho em que monta o dicionário, usando o resultado da função locals(). A função locals() retorna um dicionário com todas as variáveis locais. No exemplo acima, isso ficaria assim:

# -*- encoding: utf-8 -*-
import string,random

template='''Sugestões para %(nome)s:
 - login: %(login)s
 - email: %(email)s
 - site: www.%(domain)s.com
 - senha: %(passwd)s
'''

def sugere_logins(nome):
    login=nome.split(' ')[0].lower()
    domain=nome.split(' ')[-1].lower()
    email=login+'@'+domain+'.com'
    chars=string.letters+string.digits
    passwd=''.join(random.sample(chars,10))
    print template % locals()

Uso muito esse truque ao trabalhar com web2py, fazendo com que os controllers, ao invés de retornar um dicionário montado por mim, retornem locals().

O post Pequena dica de Python: string formatting com locals() apareceu primeiro em Elcio Ferreira.

>>> t='All your base are belong to us.'
>>> t.encode('rot-13')
'Nyy lbhe onfr ner orybat gb hf.'

Rot-13 é um encoding comum do Python. Você pode escrever código em rot-13 também, se indicar o encoding do arquivo num cabeçalho:

# -*- encoding: rot-13 -*-
vzcbeg fgevat
sbe v va enatr(20):
    cevag fgevat.nfpvv_ybjrepnfr[:v]

Salve o conteúdo acima no arquivo rot13.py e você poderá executar:

$ python rot13.py

Divertido, não?

O post Pequena dica de Python: rot-13 apareceu primeiro em Elcio Ferreira.

>>> a=[1,2,3]
>>> b=[4,5,6]
>>> c=['a','b','c']

Veja:

>>> zip(a,b,c)
[(1, 4, 'a'), (2, 5, 'b'), (3, 6, 'c')]

Simples e útil, não? E se as listas tiverem tamanhos diferentes?

>>> c=['a','b']
>>> zip(a,b,c)
[(1, 4, 'a'), (2, 5, 'b')]

O resultado será truncado para o tamanho da menor lista. Se você quiser, pode obter um comportamento diferente com map, assim:

>>> map(None,a,b,c)
[(1, 4, 'a'), (2, 5, 'b'), (3, 6, None)]

Veja um truque que eu costumava usar bastante com zip:

>>> colors=['Azul','Vermelho','Amarelo','Verde','Branco']
>>> for i in zip(range(len(colors)),colors):
...   print '%i. %s' % i
... 
0. Azul
1. Vermelho
2. Amarelo
3. Verde
4. Branco

Até que eu descobri enumerate():

>>> for i in enumerate(colors):
...   print '%i. %s' % i
... 
0. Azul
1. Vermelho
2. Amarelo
3. Verde
4. Branco

O post Pequena dica de Python: mesclando listas apareceu primeiro em Elcio Ferreira.

>>> everybody=[1,2,3,4]
>>> anybody=[0,1,0,2]
>>> nobody=[0,0,0,0]
>>> any(everybody)
True
>>> any(nobody)
False
>>> any(anybody)
True
>>> all(everybody)
True
>>> all(nobody)
False
>>> all(anybody)
False

Sem segredos, certo? Mas essas duas funções junto com os generators permite uma sintaxe muito interessante:

>>> v=[10,12,25,14]
>>> any(n>20 for n in v)
True
>>> all(n>20 for n in v)
False

Veja um exemplo disso num código real:

if all(v<100 for v in values):
    msg='Para usar seu cupom de desconto, pelo menos '+
        'um dos produtos deve custar mais de R$ 100,00.'

E numa classe real:

class Form:
    # ...
    def validates(self):
        return not any(field.error for field in self.fields)

O post Pequena dica de Python: any e all apareceu primeiro em Elcio Ferreira.