From 6dfbaf263d37d7c1cbf0e9ee45bd3240f9237b1e Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Sun, 26 Jul 2020 18:52:43 -0300 Subject: [PATCH] Commented links for 2020-07-26 --- content/links/20200726.md | 94 ++++++++++++++++++++++++++++++++++ content/links/20200726.pt.md | 98 ++++++++++++++++++++++++++++++++++++ 2 files changed, 192 insertions(+) create mode 100644 content/links/20200726.md create mode 100644 content/links/20200726.pt.md 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. + + + +## [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. + + + +## [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. + +