blog/content/links/20200531.pt.md

+++
title = "Links de 2020-05-31"
date = 2020-05-31

[taxonomies]
tags = ["links", "python", "emacs", "post-mortems", "reescritas", "rewrites",
"copyleft", "technical debt", "débito técnico", "liderando projetos",
"microserviços", "rust", "cidades", "estradas", "stallman"]
+++

Executando Coisas em Python, Emacs, Tudo Que Pode Dar Errado, Por Que
Acreditamos que Reescrever Dá Certo, Copyleft, Analogias Para Débito Técnico,
Liderando Projetos, Microserviços em Rust, Cidades Como Estadas, Reclamando de
Quem Reclama do Stallman.

<!-- more -->

## [The many ways to pass code to Python from the terminal](https://snarky.ca/the-many-ways-to-pass-code-to-python-from-the-terminal/)

Esse post é curioso. Embora eu utilize Python por um bom tempo já, alguns
desses métodos eram completos desconhecidos pra mim -- por exemplo, criar um
arquivo Zip e rodar usando diretamente o interpretador.

## [Emacs - Productivity Tricks/Hacks](http://www.mycpu.org/emacs-productivity-setup/)

Embora eu não utilize o Emacs normalmente -- eu sou usuário de Vim de
carteirinha -- eu não posso deixar de compartilhar um post sobre Emacs que
sugere o uso do Evil, o modo que utiliza as teclas do Vim.

E a sugestão de usar o Helm é algo que eu tenho que usar na minha instalação
do Emacs.

## [Postmortems](https://postmortems.info/)

Um fórum do Discord para postar coisas dando errado.

Eu tenho mencionado isso por quase um ano já: A maior parte das apresentações
que nós fizemos, quando mostramos pro público, é para falar de coisas que
acontecem de forma perfeita -- você só faz o build e ele nunca falha; você
escreve o código e nunca encontra um "corner case"; é só criar o que quiser,
tudo vai dar certo -- e isso não é a vida real.

Postmortems é um fórum justamente para descrever as coisas dando errado. E
existe muito mais que pode ser aprendido com coisas dando errado do que com os
passos perfeitos que não refletem a realidade.

## [Why do we fall into the rewrite trap?](https://www.justindfuller.com/2020/01/why-do-we-fall-into-the-rewrite-trap/)

Sim, todo mundo, nesse ponto, deve ter ouvido falar que "Refatore, Não
Reescreva". E esse post é mais do mesmo.

Mas tem algumas coisas que realmente me chamaram a atenção[^1]: Primeiro,
"Cultura do Desprezo", a ideia de que algo é ruim porque é velho e ruim, e que
a coisa nova é boa porque é nova. Eu mencionei isso no meu post de "Coisas Que
Eu Aprendi Na Marra em 30 Anos de Desenvolvimento de Software", mas
"ferramenta certa para o trabalho" nada mais é que uma forma de uma agenda e a
ferramenta certa é aquela que o seu time conhece melhor.

Ainda, ao invés de ir para "Reescrever, RUIM!" o post indica algumas situações
em que reescrever é a opção correta -- e eu não vou mostrar spoilers, mas
parece ser _realmente_ a situação correta.

## [Toward Copyleft Equality for All](https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/)

Tem um monte de coisas nesse post que serviriam apenas para repetir coisas que
eu comentei em outros: Empresas estão usando Software Livre como propaganda,
se encarregando de novas features, cobrando por isso e deixando a correção de
bugs para a comunidade, por exemplo.

Aqui, a coisa é mais complexa, e eu não sei se eu consigo ter uma opinião
concreta sobre o que está sendo dito. Basicamente, que a ideia de "copyleft" --
usar o copyright para garantir que um código vai continuar liberado e
acessível a todos -- tem sido subvertido com as "duplas licenças".

Por um lado, empresas poderiam sim deixar o código disponível e ainda cobrar
para manter o software, mas a forma como software livre tem sido usado tem
sido, na verdade, como propaganda. "Olha, é software livre!", mas escutar a
comunidade, deixar que eles apontem o destino do projeto, facilitar a
contribuição de outros, nada disso faz parte desses projetos.

## [Technical Debt Is like a Tetris Game](https://www.fluentcpp.com/2020/01/17/technical-debt-is-like-a-tetris-game/)

Essa pode ser a melhor analogia de como Débito Técnico funciona: É um jogo de
Tetris.

No começo, tudo está vazio e é simples de encaixas as peças. Mas, se você não
tomar cuidado, o jogo vai ficando cada vez mais caótico até que você perde.

Se essa não for uma explicação que todo mundo entenda porque é preciso parar
de ficar empilhando pecinhas e tentar limpar o campo de tempos em tempos, eu
realmente não sei o que vai fazer.

## [How to Lead a Project - as a Software Engineer](https://blog.pragmaticengineer.com/how-to-lead-a-project-in-software-development/)

Uma lista de coisas que engenheiros de software devem cuidar quando se tornam
líderes de projeto.

Eu posso comprovar que o conceito geral apresentado aqui funciona, porque foi
o que eu fiz quando fui líder técnico de projetos.

## [Building a Microservice with Rust](https://medium.com/@diego_pacheco/building-a-microservice-with-rust-957420f196fc)

Ok, talvez o fato que eu adore Rust pode estar relacionado com o fato d'eu
querer compartilhar algo desse tipo, mas vocês tem que concordar que esse post
é realmente complete, mostrando todos os pontos necessários para fazer um
microserviço em Rust.

## [city roads](https://anvaka.github.io/city-roads/)

Isso é um projeto curioso: Ao invés de desenhar cidades usando seus limites
geográficos, desenhe essa usando apenas as estradas.

## [Burning the House That Richard Stallman (RMS) Built: An Open Letter to GNU Maintainers Who Opposed RMS](http://techrights.org/2020/05/30/open-letter-to-gnu-maintainers/)

Vamos reclamar de quem tá reclamando?

Mais um dos posts de "Deixem rms em paz!" Dessa vez, quem trabalha para a
Microsoft -- que, estranhamente pelo tom do post, não foi chamada de 
Micro$oft -- são os piratas de verdade e quem trabalha na Red Hat é tão mal
caráter quanto.

Honestamente, não dá para negar o trabalho que o Richard Stallman fez para
promover open source. Mas ao mesmo tempo não dá pra deixar de ignorar que, por
anos, GCC ficou travado porque mudanças de arquitetura eram negadas e também
não dá pra ignorar que justamente essa "birra" em melhorar o GCC é que deu ao
Clang o espaço que ele ganhou -- lembrem-se que a Apple usava GCC inicialmente
tanto para gerar binários no Macos quanto para iOS. E também não dá para
ignorar que até um dia antes da pressão para que o rms deixasse a FSF
atingisse níveis críticos ele ainda afirmava que não havia qualquer problema
em meninas menores de idade terem relacionamentos sexuais com homens mais
velhos.

Esse tipo de pensamento -- "O cara fez muito, e pode falar o que quiser e
continuar fazendo o que quiser" -- é o mais puro pensamento adolescente de não
se preocupar com as consequências. "Oh, olhem as consequências da história da
Microsoft contra o software livre! Não, não olhem o que o rms anda falando e
como a postura dele prejudica projetos importantes e a comunidade, porque ele
é meu amigo".

A comunidade cresceu -- não apenas em número, mas também em mentalidade -- e
agora estamos nos perguntando quando é que figuras importantes vão se
responsabilizar pelo que falam e pelo que fazem.

... e é extremamente estranho ver um artigo como este que ataca a Microsoft e
a Red Hat, mas fala absolutamente NADA sobre o que o Google tem feito com o
termo "open source".

---

[^1]: ... especialmente com uma discussão que eu vi ontem de manhã.

---

Esse post foi feito com a ajuda de

* [newsbot](https://mastodon.social/@newsbot)
* [Ed S](https://mastodon.sdf.org/@EdS)
* [HN Tooter](https://mastodon.social/@hntooter)
* [codesections](https://fosstodon.org/@codesections)
* [Starfish](https://social.linux.pizza/@redstarfish)

<!-- 
vim:spelllang=pt:
-->