The source content for blog.juliobiason.me
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.

194 lines
11 KiB

<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<!-- Enable responsiveness on mobile devices-->
<!-- viewport-fit=cover is to support iPhone X rounded corners and notch in landscape-->
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1, viewport-fit=cover">
<title>Julio Biason .Me 4.3</title>
<!-- CSS -->
<link rel="stylesheet" href="https://blog.juliobiason.me/print.css" media="print">
<link rel="stylesheet" href="https://blog.juliobiason.me/poole.css">
<link rel="stylesheet" href="https://blog.juliobiason.me/hyde.css">
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface">
</head>
<body class=" ">
<div class="sidebar">
<div class="container sidebar-sticky">
<div class="sidebar-about">
<a href="https:&#x2F;&#x2F;blog.juliobiason.me"><h1>Julio Biason .Me 4.3</h1></a>
<p class="lead">Old school dev living in a 2.0 dev world</p>
</div>
<ul class="sidebar-nav">
<li class="sidebar-nav-item"><a href="&#x2F;">English</a></li>
<li class="sidebar-nav-item"><a href="&#x2F;pt">Português</a></li>
<li class="sidebar-nav-item"><a href="&#x2F;tags">Tags (EN)</a></li>
<li class="sidebar-nav-item"><a href="&#x2F;pt&#x2F;tags">Tags (PT)</a></li>
</ul>
</div>
</div>
<div class="content container">
<div class="post">
<h1 class="post-title">Links de 2020-06-01</h1>
<span class="post-date">
2020-06-01
<a href="https://blog.juliobiason.me/pt/tags/links/">#links</a>
<a href="https://blog.juliobiason.me/pt/tags/distributed/">#distributed</a>
<a href="https://blog.juliobiason.me/pt/tags/c/">#c</a>
<a href="https://blog.juliobiason.me/pt/tags/rust/">#rust</a>
<a href="https://blog.juliobiason.me/pt/tags/no-code/">#no code</a>
<a href="https://blog.juliobiason.me/pt/tags/android/">#android</a>
<a href="https://blog.juliobiason.me/pt/tags/pesquisa/">#pesquisa</a>
<a href="https://blog.juliobiason.me/pt/tags/blog/">#blog</a>
<a href="https://blog.juliobiason.me/pt/tags/contact-tracing/">#contact tracing</a>
<a href="https://blog.juliobiason.me/pt/tags/privacidade/">#privacidade</a>
</span>
<p>Sistemas Distribuídos, C em Rust, Protegendo Projetos, Sem Código, Android,
Blog de Pesquisa, Contact Tracing e Privacidade.</p>
<span id="continue-reading"></span><h2 id="notes-on-distributed-systems-for-young-bloods"><a href="https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/">Notes on Distributed Systems for Young Bloods</a></h2>
<p>Uma lista de &quot;coisas que você precisa se lembrar quando estiver trabalhando
com sistemas distribuídos&quot;, não apenas para iniciantes, mas também para
aqueles que já estão fazendo isso por algum tempo, como lembrete.</p>
<h2 id="writing-c-library-in-rust"><a href="https://www.ultrasaurus.com/2020/01/writing-c-library-in-rust/">writing c library in rust</a></h2>
<p>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í.</p>
<h2 id="self-protecting-projects"><a href="https://amihaiemil.com/2020/01/17/self-protecting-projects.html">Self-Protecting Projects</a></h2>
<p>Projetos sem um pipeline de CI/CD estão condenados ao fracasso.</p>
<p>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, &quot;toda e
qualquer função&quot; não é uma métrica).</p>
<p>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.</p>
<h2 id="the-no-code-delusion"><a href="https://www.alexhudson.com/2020/01/13/the-no-code-delusion/">The 'No Code' Delusion</a></h2>
<p>Ignorando o fato que o post que fala sobre o movimento de &quot;gerar regras de
negócio sem a necessidade de um desenvolvedor&quot;, 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 &quot;escondidas&quot; dentro de uma
função de outra regra. Nada de &quot;deixa eu botar uma regexp aqui para validar se
o email é válido ou não&quot;. 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 &quot;Você deve testar isso,
converter praquilo e enviar para aquele outro&quot;, é exatamente o que a função
deveria ter.</p>
<p>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 &quot;mostrar na tela&quot;? E assim por diante.</p>
<p>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.</p>
<h2 id="google-pushed-to-take-action-against-android-bloatware-by-50-organizations"><a href="https://9to5google.com/2020/01/11/android-bloatware-privacy-open-letter/#adnrb=900000">Google pushed to take action against Android bloatware by 50+ organizations</a></h2>
<p>Um post do começo do ano, mas tem um ponto aqui que eu quero trazer:</p>
<p>Android é &quot;open source&quot;, 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?</p>
<p>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.</p>
<p>&quot;Android é open source&quot; é uma farça. É &quot;fontes disponíveis&quot; (&quot;source
available&quot;), não &quot;open source&quot; em qualquer força de imaginação.</p>
<h2 id="why-i-keep-a-research-blog"><a href="http://gregorygundersen.com/blog/2020/01/12/why-research-blog/">Why I Keep a Research Blog</a></h2>
<p>Eu tenho pensando sobre isso por algum tempo: Eu tenho uma lista de &quot;Coisas
Que Eu Não Sei&quot; que eu mantenho no <a href="https://joplinapp.org/">Joplin</a>. 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 &quot;Ok, agora eu entendo isso&quot;.</p>
<p>Mas ao mesmo tempo, eu tenho gerado esse tipo de post (os posts dos
&quot;<a href="https://blog.juliobiason.me/pt/tags/links/">Links</a>&quot;) 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 &quot;talvez, no futuro&quot;, porque eu não coloco os
tópicos de pesquisa no meu blog também&quot;? 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.</p>
<p>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.</p>
<p>Eu ainda estou pensando nessa ideia, no entanto. Não faço nenhuma promessa que
vai acontecer.</p>
<h2 id="minnesota-is-now-using-contact-tracing-to-track-protestors-as-demonstrations-escalate"><a href="https://bgr.com/2020/05/30/minnesota-protest-contact-tracing-used-to-track-demonstrators/">Minnesota is now using contact tracing to track protestors, as demonstrations escalate</a></h2>
<p>Eu tenho comentado por algum tempo sobre o fato que aplicações de &quot;contact
tracing&quot; (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á.</p>
<p>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 <em>delegacia de polícia</em>.</p>
<p>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 &quot;contact
tracing&quot; agora estão sendo procuradas por sua associação com outros
manifestantes.</p>
<p>E é <em>isso</em> que eu tenho falado. Não existe uma política de &quot;essa informação de
contato pode ser usada <em>somente</em> para controle de disseminação de doenças e
nada mais.&quot;</p>
<hr />
<p>Esse post foi feito com a ajuda de</p>
<ul>
<li><a href="https://mastodon.social/@hntooter">HN Tooter</a></li>
<li><a href="https://botsin.space/@readrust">Read Rust</a></li>
</ul>
<!--
vim:spelllang=pt:
-->
</div>
</div>
</body>
</html>