+++
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:
-->