diff --git a/content/links/20200726.md b/content/links/20200726.md
new file mode 100644
index 0000000..96d960f
--- /dev/null
+++ b/content/links/20200726.md
@@ -0,0 +1,94 @@
++++
+title = "Commented Links for 2020-07-26"
+date = 2020-07-26
+
+[taxonomies]
+tags = ["links", "datomic", "advice", "developer", "google", "racism",
+"logging", "delete", "product manager", "syntax highlight", "highlight",
+"rust", "modules"]
++++
+
+Datomic Internals, Developer Advice, Racism@Google, Logging, Code To Delete,
+Being a Product Manager, Syntax Highlight, Rust Module System.
+
+<!-- more -->
+
+## [Unofficial guide to Datomic internals](https://tonsky.me/blog/unofficial-guide-to-datomic-internals/)
+
+Database internals are always curious, to say the least. And Datomic is also a
+curious database, as everything is immutable. 
+
+But understating internals is always good to understand where the database
+fits and how to take most of it.
+
+## [Advice to Myself When Starting Out as a Software Developer](https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/)
+
+When you're working in the field for too long, it is easy to forget how it was
+when you started.
+
+I can't find anything wrong with the tips, but they feel a bit... bland. I
+mean, honestly, the tips here are something that should be in every developers
+list anyway, beginner or pro.
+
+## [Google Ad Portal Equated “Black Girls” with Porn](https://themarkup.org/google-the-giant/2020/07/23/google-advertising-keywords-black-girls)
+
+Oh, are you saying Google is racist? That's impossible! That's "the algorithm"
+fault! Google is good, it gives me free email!
+
+You see how "giving things for free" and "open source" (and then not listening
+to users) is purely a marketing plot?
+
+## [Good Logging](https://henrikwarne.com/2020/07/23/good-logging/)
+
+Logging is always important -- personally, I think logging (and good logs) are
+more important than debugging -- but knowing _how_ and _what_ to log is the
+key for properly dealing with it.
+
+Some of the points are quite common, like screaming logs, although the
+solution is not using WARNING or INFO, but actually figuring out how to
+properly set the log level for each modules -- and using modules -- feels more
+correctly.
+
+Personally, I leave a lot of `debug` messages in some places, as "scars" of a
+battle. Maybe some future developer will see that sequence and think twice
+before jumping in.
+
+## [Write code that is easy to delete, not easy to extend.](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to)
+
+That's one thing I totally agree: it is better to write code that's easy to
+delete than to reuse. But simply going into copying things over and over so
+you can delete one thing without breaking the other is not actually the
+solution.
+
+I'd just adding abstractions, to the point functions are so simple they exist
+without any business logic; these logic pieces are then put together in other
+functions, describing _exactly_ what the business rule is:
+get_info_from_server, change_info_in_some_way, and so on. If the rule change,
+you just delete the abstraction in the middle of the larger function.
+
+"But that still doesn't solve it!" Well, if the business rule changed, then
+you can either delete the larger function and write a new one to follows the
+new rule or simply drop -- or add -- any of the abstractions.
+
+## [22 Principles for Great Product Managers](https://reeve.blog/blog/principles/)
+
+I didn't even get to half of the list and I was "yup, I had a hard time with a
+manager that didn't do that" and "I remember when they did that and it was
+awesome".
+
+## [Syntax highlighting is a waste of an information channel](https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/)
+
+Once again, "I can get behind the sentiment, but not the implementation".
+Surely, having information about types, or some parameter, in the syntax helps
+a ton, but the fact is that it depends on situation. At some point, the type
+may be more important than the parameter, or vice-versa, or worse, it may give
+focus to something that is not important at that time. Putting all that
+together, at the same time, would be a nightmare -- or a fruit salad
+of colours that would make reading the code and finding what matters completely
+impossible.
+
+## [Clear explanation of Rust’s module system](http://www.sheshbabu.com/posts/rust-module-system/)
+
+Rust module system is a bit different from everything else, and the
+exploration I did gave me some insights about it -- mostly, exactly what the
+post says.
diff --git a/content/links/20200726.pt.md b/content/links/20200726.pt.md
new file mode 100644
index 0000000..a1aad74
--- /dev/null
+++ b/content/links/20200726.pt.md
@@ -0,0 +1,98 @@
++++
+title = "Links Comentados de 2020-07-26"
+date = 2020-07-26
+
+[taxonomies]
+tags = ["links", "datomic", "dicas", "desenvolvedores", "google", "racismo",
+"logging", "logs", "deletar", "gerente de produtos", "syntax highlight",
+"highlight", "rust", "módulos"]
++++
+
+Internos do Datomic, Dicas para Desenvolvedores, Racismo@Google, Logs,
+Programe Para Deletar, Sendo um Gerente de Produtos, Syntax Highlight, Módulos
+em Rust.
+
+<!-- more -->
+
+## [Unofficial guide to Datomic internals](https://tonsky.me/blog/unofficial-guide-to-datomic-internals/)
+
+As partes internas de um banco de dados são sempre curiosas, pra dizer o
+mínimo. E Datomic é um banco de dados curioso, onde tudo é imutável.
+
+Mas entender as partes internas é sempre bom para entender onde o banco de
+dados se encaixa e como tirar o máximo disso.
+
+## [Advice to Myself When Starting Out as a Software Developer](https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/)
+
+Quando se está na área por algum muito tempo, é fácil esquecer como as coisas
+eram quando você começou.
+
+E não consigo achar nada de errado com as dicas mostradas aqui, mas eles
+parecem tão... basicas. E eu quero dizer que essas dicas são algo que deveria
+estar nas listas de todos os desenvolvedores, iniciantes ou veteranos.
+
+## [Google Ad Portal Equated “Black Girls” with Porn](https://themarkup.org/google-the-giant/2020/07/23/google-advertising-keywords-black-girls)
+
+O que? Você está dizendo que o Google é racista? Mas isso é impossível! Isso é
+culpa "do algoritmo"! Google é bom, eles me dão email de graça!
+
+Vocês conseguem ver como "dar coisas de graça" e "open source" (e não ouvir os
+usuários) não passa de uma jogada de marketing?
+
+## [Good Logging](https://henrikwarne.com/2020/07/23/good-logging/)
+
+Logs são sempre importantes -- pessoalmente, eu acho que logs (e bons logs)
+são mais importantes que debugar -- mas saber _como_ e _o que_ logar é a chave
+para fazer a coisa certa.
+
+Alguns pontos são bem comuns, como os "logs gritantes", embora a solução não
+seria usar `WARNING` e `INFO`, mas descobrir como definir corretamente o nível
+de log de cada módulo -- e usar módulos -- parece ser o mais certo.
+
+Pessoalmente, eu deixo uma pilha de mensagens de `debug` em alguns lugares,
+como "cicatrizes" de uma batalha. Talvez algum outro desenvolvedor vai ver a
+sequência de logs e pensar duas vezes antes de sair trabalhando.
+
+## [Write code that is easy to delete, not easy to extend.](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to)
+
+Essa é uma coisa que eu consigo concordar: é melhor escrever um código que
+seja fácil de ser apagado do que reusado. Mas simplesmente ir copiando
+diversas partes várias vezes para que seja possível apagar uma sem afetar o
+restado do código não parece ser a solução.
+
+Eu simplesmente iria adicionar mais abstrações, ao ponto que as funções se
+tornassem tão simples que elas existiriam sem qualquer lógica de negócio;
+essas lógicas seriam colocadas juntas em outras funções, descrevendo
+_exatamente_ o que a regra de negócio quer faz:
+recuperar_informacao_do_servidor, alterar_informacao_de_alguma_forma, e assim
+por diante. Se a regra muda, é só remover a abstração no meio da função maior.
+
+"Mas isso ainda não resolve o problema!" Bom, se a regra de negócio mudou,
+então você pode apagar a função maior e criar uma nova que segue a nova regra
+ou simplesmente apagar -- ou adicionar -- alguma das abstrações.
+
+## [22 Principles for Great Product Managers](https://reeve.blog/blog/principles/)
+
+Eu nem tinha chego na metade da lista e eu já estava "É, eu tive um gerente
+que fez minha vida um inferno" e "Eu lembro quando fizeram isso e foi ótimo".
+
+## [Syntax highlighting is a waste of an information channel](https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/)
+
+Mais uma vez, "eu concordo com o sentimento, mas não com a implementação". Não
+que ter informação sobre tipos, ou de algum parâmetro, na sintaxe não ajude um
+bocado, mas o fato é que essa informação varia conforme a situação. Em alguns
+pontos, o tipo pode ser mais importante que o parâmetro, ou vice-versa, ou,
+pior, pode dar foco em algo que não seja realmente importante no momento. E
+tentar colocar tudo isso junto, em algum ponto, se tornaria um pesadelo -- ou
+uma salada de frutas de cores que vai fazer a leitura do código e encontrar o
+que importa completamente impossível.
+
+## [Clear explanation of Rust’s module system](http://www.sheshbabu.com/posts/rust-module-system/)
+
+O sistema de módulos do Rust é um pouco diferente dos demais, e algumas
+explorações que eu fiz me deu algumas dicas sobre como esse sistema funciona
+-- mais ou menos o que é dito no post.
+
+<!-- 
+vim:spelllang=pt:
+-->