Links de 2020-06-01

Sistemas Distribuídos, C em Rust, Protegendo Projetos, Sem Código, Android, Blog de Pesquisa, Contact Tracing e Privacidade.

Notes on Distributed Systems for Young Bloods

Uma lista de "coisas que você precisa se lembrar quando estiver trabalhando com sistemas distribuídos", não apenas para iniciantes, mas também para aqueles que já estão fazendo isso por algum tempo, como lembrete.

writing c library in rust

Uma das coisas legais de Rust é que é possível combinar aplicações em Rust com qualquer outra biblioteca em C. Mas não só isso, é possível escrever código em Rust e exportar como uma interface em C -- e, com isso, combinar com qualquer outra linguagem que consiga utilizar C, que é basicamente tudo que tem por aí.

Self-Protecting Projects

Projetos sem um pipeline de CI/CD estão condenados ao fracasso.

Isso é basicamente o resumo do post e eu concordo plenamente. Existem alguns pontos faltantes, por exemplo, você pode ter um pipeline de CI/CD e não ter uma política para testes; mas, ao mesmo tempo, eu reconheço que não existe uma forma fácil de medir se estão sendo testadas as coisas certas (e não, "toda e qualquer função" não é uma métrica).

Ainda, a ideia de fazer a aplicação abrir tickets toda vez que ela capota é legal, mas isso só funciona para aplicações que rodam no seu ambiente -- seria complicado fazer uma aplicação embedded ter isso.

The 'No Code' Delusion

Ignorando o fato que o post que fala sobre o movimento de "gerar regras de negócio sem a necessidade de um desenvolvedor", o que eu achei interessante mesmo é a comparação visual da regra (um fluxograma) com o código (um trecho um Python). Por que? Porque é exatamente assim que aplicações deveriam ser escritas: Há uma lógica e ela é descrita em uma combinação de funções, cujo conteúdo não faz parte da regra e regras não estão "escondidas" dentro de uma função de outra regra. Nada de "deixa eu botar uma regexp aqui para validar se o email é válido ou não". Não é isso que a regra de negócio diz, e não é isso que o código contém. Se a regra de negócio diz "Você deve testar isso, converter praquilo e enviar para aquele outro", é exatamente o que a função deveria ter.

Por outro lado, eu não havia me ligado que mesmo descrições com fluxogramas requerem um conhecimento: Qual símbolo representa um teste? Qual símbolo representa "mostrar na tela"? E assim por diante.

O que eu não posso deixar de citar é que COBOL foi criado para que não programadores pudesse descrever as regras de negócio e executar as mesmas; SQL foi criado para que não programadores pudessem descrever como recuperar e processar dados; BDD sempre foi descrito como uma forma de não-programadores pudessem descrever as validações do sistema.

Google pushed to take action against Android bloatware by 50+ organizations

Um post do começo do ano, mas tem um ponto aqui que eu quero trazer:

Android é "open source", certo? Se é, então porque essas 50+ organizações não fazem um fork e criam o seu próprio Android? Certamente, num grupo de 50+ organizações, devem haver alguns programadores e se esses fossem colocados para trabalhar juntos, eles poderiam resolver esse problema, certo?

Bom, o fato é que o Google controla o Android. Você não pode simplesmente fazer um fork e esperar que ele irá rodar no seu dispositivo. Você não pode simplesmente fazer um pull request e esperar que ele será, um dia, parte do sistema.

"Android é open source" é uma farça. É "fontes disponíveis" ("source available"), não "open source" em qualquer força de imaginação.

Why I Keep a Research Blog

Eu tenho pensando sobre isso por algum tempo: Eu tenho uma lista de "Coisas Que Eu Não Sei" que eu mantenho no Joplin. A ideia é que, quando eu tenho algum tempo livre, ou quando eu tenho alguma informação relacionada com o tópico, eu posso adicionar na nota, até que eu me sinta com confiança suficiente para dizer "Ok, agora eu entendo isso".

Mas ao mesmo tempo, eu tenho gerado esse tipo de post (os posts dos "Links") como uma forma de manter os links que eu acho que eu vou precisar no futuro. Então, se eu mantenho uma lista de links de "talvez, no futuro", porque eu não coloco os tópicos de pesquisa no meu blog também"? Por enquanto, eu só vou ter os tópicos e nada de conteúdo (desculpem-me!) mas deixar os mesmos disponíveis pode ajudar mais alguém.

Existe um ponto que tem que ser feito: Se eu compartilho links, porque não compartilhar links relacionados com esses tópicos e deixo a ferramenta de blog que eu uso se preocupar em agrupar essas informações? A ideia é descrever a informação com meus minhas próprias palavras, porque essas são mais fáceis de lembrar no futuro.

Eu ainda estou pensando nessa ideia, no entanto. Não faço nenhuma promessa que vai acontecer.

Minnesota is now using contact tracing to track protestors, as demonstrations escalate

Eu tenho comentado por algum tempo sobre o fato que aplicações de "contact tracing" (pessoas com quem o usuário do celular teve proximidade) podem soar boas para encontrar alguém que teve contato com outra pessoa que teve COVID-19 (de forma que essa pessoa possa ser alertada e/ou levada para um hospital, antes que os sintomas se tornem muito fortes para qualquer tratamento), mas que haviam sérios problemas de privacidade com eles? Bom, aqui está.

Uma pessoa negra foi brutalmente morta pela polícia nos EUA, e a comunidade se amotinou ao ponto de que uma delegacia de polícia foi queimada -- eu não estou dizendo que está certo ou errado, mas vocês tem que pensar no tipo de indignação que faz com que pessoas botem fogo numa delegacia de polícia.

E as pessoas que se preocuparam que elas poderiam entrar em contato com alguém que fosse infectado pelo COVID-19 e instalaram qualquer aplicação de "contact tracing" agora estão sendo procuradas por sua associação com outros manifestantes.

E é isso que eu tenho falado. Não existe uma política de "essa informação de contato pode ser usada somente para controle de disseminação de doenças e nada mais."

Esse post foi feito com a ajuda de

• HN Tooter
• Read Rust