4.8 KiB
+++ 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.
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
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
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
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.
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
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
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
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.