Browse Source

Links for 2020-06-04

master 20200604
Julio Biason 4 years ago
parent
commit
29fb4cc7e6
  1. 130
      content/links/20200601.md
  2. 142
      content/links/20200601.pt.md
  3. 116
      content/links/20200604.md
  4. 126
      content/links/20200604.pt.md

130
content/links/20200601.md

@ -0,0 +1,130 @@
+++
title = "Links for 2020-06-01"
date = 2020-06-01
[taxonomies]
tags = ["links", "distributed", "c", "rust", "protection", "no code",
"android", "research", "blog", "contact tracing", "privacy"]
+++
Distributed Systems, C in Rust, Protecting Projects, No Code, Android,
Research Blog, Contact Tracing and Privacy (again).
<!-- more -->
## [Notes on Distributed Systems for Young Bloods](https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/)
A bunch of "things you need to remember when working on distributed systems",
not only for "young bloods", but also for those who are doing this for
sometime, just as a reminder.
## [writing c library in rust](https://www.ultrasaurus.com/2020/01/writing-c-library-in-rust/)
One of the cool things about Rust is that you can combine Rust applications
with any other C library. But not only that, it is also possible to write code
in Rust and export it as a C interface -- and, with that, combine with any
other language that can bind with C, which are basically every language around.
## [Self-Protecting Projects](https://amihaiemil.com/2020/01/17/self-protecting-projects.html)
Projects without a CI/CD pipeline are doomed to fail.
That's basically the gist of the post and I'm all for it too. There are a few
missing bits, like you can have a CI/CD pipeline and not having a policy for
writing tests; but, at the same time, I reckon there is no easy way to measure
if the proper things are being tested (and no, "every single function" is not
a measure).
Also, the idea of making the application open tickets every time the
application crashes is cool and all, but that only works for applications that
run on your own environment -- an embedded application would have a hard time
making this.
## [Why I Keep a Research Blog](http://gregorygundersen.com/blog/2020/01/12/why-research-blog/)
I've been thinking about this for some time: I have a list of "Things I Don't
Know", which I keep on [Joplin](https://joplinapp.org/). The idea is that,
when I have some time, or when I see some information related to the topic, I
can add to the note, till I finally feel confident enough to say "Ok, now I
understand this".
But for some time I've been writing this kind of post (the
"[Links](https://blog.juliobiason.me/tags/links/)" ones) as a way to keep a
list of things that I feel I may need in the future. So, if I keep a list of
"maybe in the future" links, why don't I put the research topics also in this
blog? Surely, right now, it will have only the topics and no content (sorry!)
but making it available may also help someone else.
There is one point that one could make: If I share links, why not share links
related to those topics, and let the blog engine worry about grouping them?
The point is actually to write whatever I learnt in my own words, 'cause those
are easier to recall in the future.
I'm still wrangling with the idea, though. No promises.
## [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/)
You may recall that I've been, for a while, mentioning that contact tracing
applications may sound good to find someone that had contact with another
someone with COVID-19 (so we could alert and/or take that person to a
hospital, before it was too late for treatment), but there were serious
privacy problems with it? Well, there we go.
A black person was brutally killed by the police in the USA, and the community
rioted to the point that a police department was set afire -- I'm not saying
it was right or wrong, but you have to think the type of indignation that make
people set a _police department_ on fire.
And those people who worried that they may get in contact with someone that
got infected with COVID-19 and installed any contact tracing application are
now being tracked by their association with other demonstrators.
And _that's_ what I was talking about. There is no policy that says "this
tracing information may be _only_ used for diseases and nothing else".
## [The 'No Code' Delusion](https://www.alexhudson.com/2020/01/13/the-no-code-delusion/)
Ignoring the fact that the post talks about a movement for "creating
business rules without the need of a developer", what I found interesting is
the visual comparison of the business rule (in a diagram) and the code (a
piece of Python code). Why? Because that's exactly the way applications should
be written: There is logic and it is described in a combination of functions,
which content doesn't make part of the rule itself and there are no rules
"hidden" inside the function of a rule. There is nothing of "let me put a
regexp here to validate the email". That's not what the business rule says, so
that's not in the code. If the business rule said "You should test this,
convert to that and send this to there", that's exactly what the function
should have.
On the other hand, I didn't realized that diagrams require some previous
knowledge: Which symbol represents a test? Which symbol represents "white in
the screen"? And so on.
What I need to mention, though, is that COBOL was created for non-programmers
so they could describe business rules and run them; SQL was desgiedn so
non-programmers could describe how to retrieve and process data; BDD has
always been described as a way for non-programmers to describe how a system
should be validated.
## [Google pushed to take action against Android bloatware by 50+ organizations](https://9to5google.com/2020/01/11/android-bloatware-privacy-open-letter/#adnrb=900000)
A post from earlier this year, but there is one point that I need to bring:
Android is "open source", right? If it is, why doesn't those 50+ organizations
just fork it and make their own Android? Surely, in a 50+ organization group,
there should be a few developers and making them all work on that could solve
the problem, right?
Well, thing is, Google controls Android. You can't simply fork and hope that
you can run on your device. You can't simply make a pull request and hope it
will, one day, be part of the system.
"Android is opensource" is a farce. It is "source available", not "open
source" by any stretch of imagination.
---
This post was built with the help of
* [HN Tooter](https://mastodon.social/@hntooter)
* [Read Rust](https://botsin.space/@readrust)

142
content/links/20200601.pt.md

@ -0,0 +1,142 @@
+++
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:
-->

116
content/links/20200604.md

@ -0,0 +1,116 @@
+++
title = "Commented Links for 2020-06-03"
date = 2020-06-03
[taxonomies]
tags = ["links", "rust", "scotty", "python", "pyramid", "cornice", "datetime",
"mercurial", "async requests", "httpx", "advertising", "google", "python 3"]
+++
Scotty, Pyramid and Cornice, Problems with `datetime.now()`, Mercurial and
Python 3, Fast Python, Async Python Request Library, Online Advertising,
Google and Web.
<!-- more -->
## [scotty: Transports you to any directory you have visited before](https://github.com/wdullaer/scotty)
I have been using Scotty for some time and I really like it.
What Scotty does is keep a list of directories you accessed recently and,
after a while, you can simply use `s <directory>` to get straight into it. Not
only that, but Scotty uses fuzzy searching to find the directory that closely
matches whatever you typed.
## [How to write a Python web API with Pyramid and Cornice](https://opensource.com/article/20/1/python-web-api-pyramid-cornice)
Pyramid is the "less known" Python web framework around. But this post shows
how simple is to build a (simple) API with it.
## [Stop Using datetime.now!](https://hakibenita.com/python-dependency-injection)
Slightly clickbait title, but great content. Not only pointing out the
problems when using `datetime.now()` (no, it's not the function itself that
has a problem, it is the way we use that may cause problems), but going into
lenghts explaining dependency injection in Python.
## [Mercurial's Journey to and Reflections on Python 3](https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/)
Ding dong, the witch is dead, and so is Python 2.
But there is still a large base of Python 2 projects that need to be converted
to Python 3, and Mercurial did this, and here's the experience of a
maintained on doing it so.
I do understand that converting Python 2 to 3 is not a simple task, but there
are a few misconceptions in the post. For example, "the approach of assuming
the world is Unicode is flat out wrong and has significant implications for
systems level applications". The word _is_ unicode. Go read the Portuguese
version of this blog to have some idea. Go read any Chinese/Japonese blog to
see how it looks. Do you really think those people do not use system level
applications anywhere? Also, what do you think are mostly used: User level
applications or system level?
Not saying the conversion is perfect -- in a way, unicode is simply a way of
dealing with the underlying bytes -- but ranting that this change made _your_
specific way to think harder is not an excuse to not understand where the
whole ecosystem was moving -- and it also doesn't mean your specific thing is
not welcome, but you have to understand you're in the minority case here.
(Also, it's no surprise to me that claiming "world is unicode is wrong" is
coming from someone living in an ASCII country.)
## [Making Python Programs Blazingly Fast](https://martinheinz.dev/blog/13)
A set of tips on how to make Python applications faster. Some of those may
seem weird in the first glance (make a variable in the function point to the
a variable in the same class?) but the post also explains _why_ this may
improve the general performance.
## [Httpx: A next-generation HTTP client for Python](https://www.python-httpx.org/)
[Requests](https://2.python-requests.org/en/master/) shown to everyone how
APIs should work, but it kinda got stuck in time, without async support (and a few
other glitches in the project management). Now there is Httpx, which is,
again, another HTTP request library, but this time with async support and,
basically, the same interface.
## [No-judgment digital definitions: Online advertising strategies](https://blog.mozilla.org/firefox/online-advertising-strategies/)
Have you ever wondered why after you search something -- say, "gamer chair" --
suddenly you start getting a lot of promotions and ads for chairs in your
social networks?
Nothing happens by simple chance, and that's the effect of all the trackers
that someone puts on a page. But how they identify who is who is the real
question.
This post by Mozilla may seem a little bit basic, but shows pretty damn well
how those things are done.
## [Google Is Not God of The Web](https://bilge.world/google-page-experience)
Another clickbait title but, again, good content.
A point that caught my attention was "Google has the right to dictate 'Best
Practices', although I think the topic is quite the opposite, based on its
content.
Imagine that Google start giving points of "user experience" to pages that use
the Material design. Pages and pages that look like Android apps. But if you
use your own layout, your own colors, you lose points. What now?
This is the greatest problem on people depending on Google, and all the
relationship of one of their groups working on web standards, a group working
on a browser and a group to take advantage of whatever the previous two did.
The less dependent on Google you become, the more you use alternative search
engines (DuckDuckGo, Searx and even Bing), the more you use other email
providers (ProtonMail), the more you use browsers that are not Chrome
(Firefox, Safari or anything based on WebKit), the lesser the chance of the
internet becoming the thing of a single company.
---
This post was built with the help of
* [HN Tooter](https://mastodon.social/@hntooter)

126
content/links/20200604.pt.md

@ -0,0 +1,126 @@
+++
title = "Links Comentados de 2020-06-03"
date = 2020-06-03
[taxonomies]
tags = ["links", "rust", "scotty", "python", "pyramid", "cornice", "datetime",
"python 3", "mercurial", "requisições async", "propaganda", "google"]
+++
Scotty, Pyramid e Cornice, Os Problemas Com `datetime.now()`, Mercurial e
Python 3, Acelerando o Python, Biblioteca Async para Requisições HTTP,
Propagandas Digitais, Google e a Web.
<!-- more -->
## [scotty: Transports you to any directory you have visited before](https://github.com/wdullaer/scotty)
Eu tenho usado Scotty por algum tempo já e realmente tem me agradado.
O que Scotty faz é guardar uma lista dos diretórios pelos quais você já passou
e, depois de um tempo, você pode simplesmente fazer `s <diretório>` e cair
diretamente no diretório específico. Não apenas isso, mas `<diretório>` nem
precisa ser o nome correto do diretório; Scotty usa "fuzzy search" para
encontrar o diretório com o nome mais parecido com o que você digitou.
## [How to write a Python web API with Pyramid and Cornice](https://opensource.com/article/20/1/python-web-api-pyramid-cornice)
Pyramid is o framework web para Python menos conhecido por aí. Mas esse post
mostra como é simples fazer uma (simples) API com ele.
## [Stop Using datetime.now!](https://hakibenita.com/python-dependency-injection)
Embora o título seja um pouco "clickbait", o conteúdo é bem interessante. Não
apenas apontando os problemas de se usar `datetime.now()` (não, não é a função
em si que tem um problema, é a forma como usamos o resultado que pode gerar
problemas), mas explicando minuciosamente injeção de dependências em Python.
## [Mercurial's Journey to and Reflections on Python 3](https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/)
Ding dong, a bruxa morreu, e o Python 2 também.
Mas ainda existe uma grande base de projetos em Python 2 que precisam ser
convertidos para Python 3, e o Mercurial fez isso, e aqui tem a experiencia do
mantenedor em fazer essa conversão.
Eu entendo que converter um projeto de Python 2 para 3 não é uma tarefa fácil,
mas tem algumas coisas erradas no post. Por exemplo, "the approach of assuming
the world is Unicode is flat out wrong and has significant implications for
systems level applications" (a ideia de assumir que o mundo é unicode é
completamente errada e tem sérias implicações para aplicações que nível de
sistema). O mundo _é_ unicode. É só ler a parte em português desse site. É só
ler um blog em chinês ou japonês para ver como ele é. Você realmente acredita
que essas pessoas não usam aplicações de sistema em lugar algum? Ainda, o que
você acham que são mais usadas: Aplicações de nível de sistema ou nível de
usuário?
Não estou dizendo que a conversão é perfeita -- de certa forma, unicode
simplesmente é uma forma de tratar os bytes que estão por baixo -- mas
reclamar que a mudança fez a _sua_ forma de pensar mais difícil não é desculpa
para não entender para onde o eco sistema está indo -- e também não quer dizer
que o seu projeto específico não é bem-vindo, mas você tem que entender que
está no caso minoritário aqui.
(E também não me surpreende que alguém dizendo que "mundo em unicode está
errado" vem de alguém que vive num país ASCII.)
## [Making Python Programs Blazingly Fast](https://martinheinz.dev/blog/13)
Um conjunto de dicas de como fazer aplicações Python funcionarem mais rápido.
Algumas coisas podem não parecer fazer muito sentido (colocar uma variável
apontando pra outra dentro da mesma classe?), mas o post pelo menos explica
_por que_ isso ajuda na performance.
## [Httpx: A next-generation HTTP client for Python](https://www.python-httpx.org/)
[Requests](https://2.python-requests.org/en/master/) mostrou pra todo mundo
como APIs devem funcionar, mas o projeto meio que ficou parado no tempo, sem
suporte a chamadas async (e alguns outros probleminhas na gerencia do
projeto). Agora existe Httpx, que é outra biblioteca para fazer requisições
HTTP, mas dessa vez com suporte a async e basicamente a mesma interface.
## [No-judgment digital definitions: Online advertising strategies](https://blog.mozilla.org/firefox/online-advertising-strategies/)
Já se perguntou como é que depois de pesquisar alguma coisa -- por exemplo,
"cadeiras gamer" -- de repente começam a surgir promoções e propagandas de
cadeiras na sua rede social?
Nada acontece por acaso, e isso é um efeito de todos os trackers que são
colocados numa página. Mas como é que eles identificam quem é quem é que é a
questão.
Esse artigo da Mozilla, embora pareça meio básico para quem acompanha, mostra
bem como essas coisas funcionam.
## [Google Is Not God of The Web](https://bilge.world/google-page-experience)
Outro título um pouco "clickbait" mas, de novo, conteúdo interessante.
Um ponto que me chamou a atenção foi "Google has the right to dictate 'Best
Practices.'" (Google tem o direito de ditar o que são as "boas práticas") que
apesar do título diz exatamente o contrário.
Imaginem vocês que o Google comece a dar notas de "experiência de uso" para
páginas que adotem o visual do Material. Páginas e páginas que parecem com
aplicativos Android. Mas se você utilizar o seu próprio layout, seu próprio
conjunto de cores, você vai perder pontos. E agora?
Esse é o grande problema da dependência que as pessoas tem com o Google, e
toda a simbiose que o mesmo tem tendo um grupo trabalhando para padrões da
web, um grupo trabalhando para fazer um browser e um grupo pra tirar proveito
do trabalho dos dois anteriores. Quando menos você usar o Google, quanto mais
você usar ferramentas de pesquisa alterativos (DuckDuckGo, Searx, e até mesmo
o Bing), quanto mais você usar outros provedores de email (ProtonMail), quanto
mais vocês usarem browsers que não sejam Chrome (Firefox, Safari, ou algum
outro baseado em WebKit), menor vai ser a probabilidade de que a internet se
torne um ambiente de uma empresa só.
---
Esse post foi feito com a ajuda de
* [HN Tooter](https://mastodon.social/@hntooter)
<!--
vim:spelllang=pt:
-->
Loading…
Cancel
Save