Browse Source

Links for 2020-05-31

master
Julio Biason 5 years ago
parent
commit
2653a4db9e
  1. 158
      content/links/20200531.md
  2. 165
      content/links/20200531.pt.md

158
content/links/20200531.md

@ -0,0 +1,158 @@
+++
title = "Links for 2020-05-30"
date = 2020-05-30
[taxonomies]
tags = ["links", "python", "emacs", "post-mortems", "rewrites", "copyleft",
"technical debt", "leading", "microservices", "rust", "cities", "roads",
"stallman"]
+++
Running Things in Python, Emacs, Everything That Can Go Wrong, Why We Believe
that Rewrites Go Right, Copyleft, Analogies for Technical Debt, Leading
Projects, Microservices in Rust, Cities as Roads, Complaining about 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/)
This is a curious post. Although I've been using Python for a long time,
some of those were completely unknowns to me -- for example, making a zip file
and running it directly with the interpreter.
## [Emacs - Productivity Tricks/Hacks](http://www.mycpu.org/emacs-productivity-setup/)
Although I don't usually use Emacs -- I'm a Vim user myself -- I can't stop
myself from sharing a post about Emacs that suggests using Evil, the Vim
keybinds emulation mode.
And the suggestion of using Helm is something that I really need to add on my
Emacs configuration.
## [Postmortems](https://postmortems.info/)
A Discord place for posting things going wrong.
I've been mentioning this for a year already: Most presentations we do, when
we go in public, is to talk about the things the go perfecting fine -- you
just do a build, it will never fail; just write the code, you won't find a
corner case; just create something, everything will be fine -- and that's not
the real life.
Postmortens is a forum exactly for describing things going wrong. And there is
a lot more to learn from things going wrong than from perfect steps that does
not reflect reality.
## [Why do we fall into the rewrite trap?](https://www.justindfuller.com/2020/01/why-do-we-fall-into-the-rewrite-trap/)
Yes, everybody, at this point, heard about the "Refactor, Don't Rewrite". And
this is just more of that.
But there are some things that really caught my eye[^1]: First, "Contempt
Culture", the idea that something is bad because it's old and bad and the new
thing is good because it's new. I mentioned this on my "Things I Learnt The
Hard Way in 30 Years of Software Development", but "right tool for the job" is
mostly a way to push an agenda and the right tool is mostly the tool your team
knows the best.
Also, instead of just going through "Rewrite BAD!", it actually list some
situations when doing a rewrite is the right option -- and I won't spoil, but
it does seems _really_ the right situation.
## [Toward Copyleft Equality for All](https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/)
A lot of the things in this post would be just for me to repeat things I
pointed in other posts: Companies are using the Free Software label just as
marketing, working on new features and charging for it, while leaving the
bugfixing part to the community, for example.
Here, the thing is a bit more complex, and I'm not sure if I can have an
concrete opinion about what is being said. Basically, the idea of
"copyleft" -- using copyright to make sure the code will still be available
and accessible to everything -- has been been subverted with the "dual
licensing".
In one hand, companies should be able to let the code be available and still
charge for it, but the way they have been using free software seems to be only
as a marketing plot. "Look, it's free software!" but listen to the community,
let them point the destiny of the project, making sure contributing is easy,
nothing of that makes part of those projects.
## [Technical Debt Is like a Tetris Game](https://www.fluentcpp.com/2020/01/17/technical-debt-is-like-a-tetris-game/)
This may be the best Technical Debt analogy I ever seen: It is a game of
Tetris.
In the start, everything is clear and it is simple to fit the pieces. But, if
you don't take the time to clear things from time to time, it will get more
and more chaotic till you lose.
If this isn't an explanation that everyone understands why you need to stop
from just piling up pieces and try to clear the field from time to time, I
really don't know what will.
## [How to Lead a Project - as a Software Engineer](https://blog.pragmaticengineer.com/how-to-lead-a-project-in-software-development/)
A list of things software engineers should take care when they become project
leaders.
I can attest that the general concept here works, 'cause that's what I did
when I was technical leader in projects.
## [Building a Microservice with Rust](https://medium.com/@diego_pacheco/building-a-microservice-with-rust-957420f196fc)
Ok, the fact that I love Rust may be related to me wanting to share this, but
you have to agree that the post is really complete, showing all the hops and
jumps you need to do to make a microservice in Rust.
## [city roads](https://anvaka.github.io/city-roads/)
This is a cool project: Instead of drawing a city using its geographical
limits, draw it using their roads.
## [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/)
Let's complain about those complaining?
Another one of those "Leave rms alone!" kind of posts. This time, whoever
works for Microsoft -- which is extremely weird for this kind of post for not
calling it Micro$oft -- are the real pirates and who works for Red Hat have as
bad character as them.
Honestly, there is no denying in the work Richard Stallman did to promote free
software. But, at the same time, we can't ignore that, for years, GCC got
stuck on its architecture 'cause any changes were denied and we can't deny
that this "tantrum" in improving GCC is what gave Clang the space it got --
just remember that Apple used GCC to build macOS and iOS binaries. And we
can't ignore that just one day before the pressure for rms to leave the FSF
reached critical levels he was still saying that there was no problem in an
underage girl to have a sexual relationship to an old man.
This kind of though -- "But he did lots, and can say and do whatever he
wants" -- it's the most pure teenage thought of no worrying about the
consequences. "Oh, look at the consequences in the history of Microsoft
against free software! But don't look on what rms is saying and how his
posture hurts important projects and the community, 'cause he's my friend".
The community has grown up -- not only in numbers, but also in its mental
age -- and now we are asking when important figures will be hold responsible
for whatever they say and whatever they do.
... and it is really weird for a post like this that attacks Microsoft and
Red Hat, but says absolutely NOTHING about what Google has been doing with the
term "open source".
---
[^1]: ... specially since I saw some things related to this yesterday
morning...
---
This post was built with the help of
* [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)

165
content/links/20200531.pt.md

@ -0,0 +1,165 @@
+++
title = "Links de 2020-05-30"
date = 2020-05-30
[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:
-->
Loading…
Cancel
Save