Links for 2020-06-04

5 years ago · 29fb4cc7e6
4 changed files with 514 additions and 0 deletions
--- a/content/links/20200601.md
+++ b/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)
--- a/content/links/20200601.pt.md
+++ b/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:
 -->
--- a/content/links/20200604.md
+++ b/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)
--- a/content/links/20200604.pt.md
+++ b/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:
 -->