You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
143 lines
7.0 KiB
143 lines
7.0 KiB
4 years ago
|
+++
|
||
|
title = "Links de 2020-06-01"
|
||
|
date = 2020-06-01
|
||
|
|
||
|
[taxonomies]
|
||
|
tags = ["links", "distributed", "c", "rust", "no code", "android", "pesquisa",
|
||
|
"blog", "contact tracing", "privacidade"]
|
||
|
+++
|
||
|
|
||
|
Sistemas Distribuídos, C em Rust, Protegendo Projetos, Sem Código, Android,
|
||
|
Blog de Pesquisa, Contact Tracing e Privacidade.
|
||
|
|
||
|
<!-- more -->
|
||
|
|
||
|
## [Notes on Distributed Systems for Young Bloods](https://www.somethingsimilar.com/2013/01/14/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](https://www.ultrasaurus.com/2020/01/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](https://amihaiemil.com/2020/01/17/self-protecting-projects.html)
|
||
|
|
||
|
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](https://www.alexhudson.com/2020/01/13/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](https://9to5google.com/2020/01/11/android-bloatware-privacy-open-letter/#adnrb=900000)
|
||
|
|
||
|
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](http://gregorygundersen.com/blog/2020/01/12/why-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](https://joplinapp.org/). 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](https://blog.juliobiason.me/pt/tags/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](https://bgr.com/2020/05/30/minnesota-protest-contact-tracing-used-to-track-demonstrators/)
|
||
|
|
||
|
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](https://mastodon.social/@hntooter)
|
||
|
* [Read Rust](https://botsin.space/@readrust)
|
||
|
|
||
|
<!--
|
||
|
vim:spelllang=pt:
|
||
|
-->
|
||
|
|