Merge branch 'release/20200726.1'

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.

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

content/quotes/albert-einstein/index.md

@@ -4,7 +4,7 @@ weight = 97
 
 [taxonomies]
 tags = ["quotes", "albert einstein", "einstein", "cleverness", "theory",
-"facts", "imagination"]
+"facts", "imagination", "stupidity"]
 +++
 
 > "Man usually avoids attributing cleverness to somebody else -- unless it
@@ -16,3 +16,7 @@ tags = ["quotes", "albert einstein", "einstein", "cleverness", "theory",
 
 > "Life is like riding a bicycle. Too keep your balance, you must keep
 > moving."
+
+> "The difference between genius and stupidity is that genius has it's
+> limits."
+

content/quotes/aldous-huxley/index.md

@@ -3,7 +3,7 @@ title = "Aldous Huxley"
 weight = 97
 
 [taxonomies]
-tags = ["quotes", "aldous huxley", "dictatorship"]
+tags = ["quotes", "aldous huxley", "dictatorship", "experience"]
 +++
 
 > "The perfect dictatorship would have the appeareance of a democracy, but
@@ -11,3 +11,7 @@ tags = ["quotes", "aldous huxley", "dictatorship"]
 > even dream of escaping. It would essentially be a system of slavery where,
 > thought consumption and entertainment, the slaves would love their
 > servitudes."
+
+> "Experience is not what happens to you; it is what you do with what happens
+> to you."
+

content/quotes/george-wald/index.md

@@ -0,0 +1,9 @@
++++
+title = "George Wald"
+weight = 103
+
+[taxonomies]
+tags = ["quotes", "george wald", "atoms", "physics"]
++++
+
+> "A physicist is an atom's way of knowing about atoms."

content/quotes/grace-hopper/index.md

@@ -0,0 +1,9 @@
++++
+title = "Grace Hopper"
+weight = 103
+
+[taxonomies]
+tags = ["quotes", "grace hopper"]
++++
+
+> "The most dangerous phrase in the language is, 'We've always done it this way.'"

content/quotes/h-h-williams/index.md

@@ -0,0 +1,9 @@
++++
+title = "H. H. Williams"
+weight = 104
+
+[taxonomies]
+tags = ["quotes", "h h williams"]
++++
+
+> "Furious activity is no substitute for understanding."

content/quotes/h-l-mencken/index.md

@@ -3,7 +3,10 @@ title = "H. L. Mencken"
 weight = 104
 
 [taxonomies]
-tags = ["quotes", "h l mencken", "conscience"]
+tags = ["quotes", "h l mencken", "conscience", "politics"]
 +++
 
 > "Conscience is a mother-in-law whose visit never ends."
+
+> "Going into politics is as fatal to a gentleman as going into a bordello
+> is fatal to a virgin."

content/quotes/hal-hickman/index.md

@@ -0,0 +1,11 @@
++++
+title = "Hal Hickman"
+weight = 104
+
+[taxonomies]
+tags = ["quotes", "hal hickman", "opinions"]
++++
+
+> "Opinions are like assholes -- everyone's got one, but nobody wants to look
+> at the other guy's."
+

content/quotes/julius-lester/index.md

@@ -0,0 +1,11 @@
++++
+title = "Julius Lester"
+weight = 106
+
+[taxonomies]
+tags = ["quotes", "julius lester", "riots"]
++++
+
+> "Black people have never rioted. A riot is what white people think blacks
+> are involved in when they burn stores."
+

content/quotes/mark-twain/index.md

@@ -4,7 +4,7 @@ weight = 109
 
 [taxonomies]
 tags = ["quotes", "mark twain", "annoyance", "examples", "fame", "writing",
-"right", "speeches", "heaven", "hell"]
+"right", "speeches", "heaven", "hell", "generalizations"]
 +++
 
 > "Few things are harder to put up with than the annoyance of a good example."
@@ -26,3 +26,5 @@ tags = ["quotes", "mark twain", "annoyance", "examples", "fame", "writing",
 > "Go to Heaven for the climate, Hell for the company."
 
 > "Water, taken in moderation cannot hurt anybody."
+
+> "All generalizations are false, including this one."

content/quotes/nikolai-kingsley/index.md

@@ -0,0 +1,11 @@
++++
+title = "Nikolai Kingsley"
+weight = 110
+
+[taxonomies]
+tags = ["quotes", "nikolai kingsley"]
++++
+
+> "Don't fear the darkness.
+> Fear the things that hide in the darkness.
+> Then become one of those things, and let them feat you."

content/quotes/ogden-nash/index.md

@@ -3,9 +3,12 @@ title = "Ogden Nash"
 weight = 111
 
 [taxonomies]
-tags = ["quotes", "ogden nash", "cats"]
+tags = ["quotes", "ogden nash", "cats", "goods"]
 +++
 
 > "The trouble with a kitten is that
 > When it grows up, it's always a cat"
 
+> "People who have what they want are very fond of telling people who haven't
+> what they want that they don't want it."
+

content/quotes/random/index.md

@@ -7,7 +7,7 @@ tags = ["quotes", "graffiti", "education", "misery", "distributed systems",
 "the day the earth stood still", "atheism", "religion", "following",
 "regrets", "money", "perfection", "practice", "nerds", "totalitarianism",
 "materialism", "god", "time", "privacy", "guests", "proverbs", "russian",
-"incompetence", "insanity", "instagram"]
+"incompetence", "insanity", "instagram", "leadership"]
 +++
 
 > If you took all the students that felt asleep in class and laid them end to
@@ -104,3 +104,10 @@ tags = ["quotes", "graffiti", "education", "misery", "distributed systems",
 > "Don’t say condemn it because it can happen to you one day. Condemn it
 > because it is wrong."
 -- mysticashi@mastodon.social
+
+> "He that would govern others, first should be the master of himself."
+
+> "To err is human.
+> To blame someone else for your mistakes is even more human."
+
+

content/quotes/robert-benchley/index.md

@@ -0,0 +1,11 @@
++++
+title = "Robert Benchley"
+weight = 114
+
+[taxonomies]
+tags = ["quotes", "robert benchley", "work"]
++++
+
+> "Anyone can do any amount of work provided it isn't the work he is supposed
+> to be doing at the moment."
+

content/quotes/thomas-edison/index.md

@@ -0,0 +1,10 @@
++++
+title = "Thomas Edison"
+weight = 116
+
+[taxonomies]
+tags = ["quotes", "thomas edison", "religion"]
++++
+
+> "All Bibles are man-made."
+

content/quotes/titus-lucretius-carus/index.md

@@ -0,0 +1,9 @@
++++
+title = "Titus Lucretius Carus"
+weight = 116
+
+[taxonomies]
+tags = ["quotes", "titus lucretius carus", "life"]
++++
+
+> "Life is one long struggle in the dark."

content/quotes/wilhelm-reich/index.md

@@ -0,0 +1,11 @@
++++
+title = "Wilhelm Reich"
+weight = 119
+
+[taxonomies]
+tags = ["quotes", "whilhelm reich", "hitler", "politics", "politicians"]
++++
+
+> "The fact that Hitler was a political genius unmasks the nature of politics
+> in general as no other can."
+

content/quotes/woody-allen/index.md

@@ -0,0 +1,10 @@
++++
+title = "Woody Allen"
+weight = 119
+
+[taxonomies]
+tags = ["quotes", "woody allen"]
++++
+
+> "The lion and the calf shall lie down together but the calf won't get much
+> sleep."

content/reviews/books/21st-century-robot.md

@@ -3,7 +3,8 @@ title = "21st Century Robot: The Dr. Simon Egerton Stories - Brian David Johnson
 date = 2020-07-04
 
 [taxonomies]
-tags = ["books", "reviews", "david johnson", "robotics", "it", "2 stars"]
+tags = ["books", "reviews", "david johnson", "robotics", "it", "2 stars",
+"2020 challenge"]
 +++
 
 [GoodReads Summary](https://www.goodreads.com/book/show/16087659-21st-century-robot):

content/reviews/books/introducing-elixir.md

@@ -0,0 +1,31 @@
++++
+title = "Introducing Elixir: Getting Started in Functional Programming - Simon St.Laurent, J. David Eisenberg"
+date = 2020-07-24
+
+[taxonomies]
+tags = ["books", "reviews", "simon st laurent", "j david eisenberg", "it",
+"elixir", "2020 challenge", "4 stars"]
++++
+
+[GoodReads Summary](https://www.goodreads.com/book/show/18194084-introducing-elixir):
+Authors Simon St. Laurent and J. David Eisenberg show you how to write simple
+Elixir programs by teaching you one skill at a time. You'll learn about
+pattern matching, recursion, message passing, process-oriented programming,
+and establishing pathways for data rather than telling it where to go. By the
+end of your journey, you'll understand why Elixir is ideal for concurrency and
+resilience.
+
+<!-- more -->
+
+{{ stars(stars=4) }}
+
+In a way, this is an "Introducing" book, so one shouldn't expect some deep
+knowledge about the language after reading it.  But also, sometimes it feels a
+bit too "shallow" to gather some proper understanding of the language. 
+
+One thing that kept bugging me was the fact that code kept changing: Not in
+the "going forward" kind of change, which is good, explain the basic, then
+start adding more complex/shorter solutions, but "let me bend this to another
+direction and completely ignore that direction later".
+
+But to get a "feeling" of the language, it is a good book.

content/thoughts/how-to-kill-developer-productivity.md

@@ -0,0 +1,63 @@
++++
+title = "How to Kill Developer Productivity"
+date = 2020-07-20
+
+[taxonomies]
+tags = ["developers", "productivity", "programming", "ti", "onboarding", 
+"data flow", "architecture"]
++++
+
+There are several ways to not kill developer productivity in a project.
+Unfortunately, the real causes are never discussed.
+
+<!-- more -->
+
+Recently I read another post about "how to not kill your developer
+productivity", that says exactly what every other post about it says:
+Basically, "do not interrupt".
+
+But can we really avoid interruptions? Isn't the "ping!" from the coffee
+machine an interruption? Isn't a full bladder an interruption? Isn't the front
+door bell ringing when a package and/or food delivery an interruption?
+
+What's the difference between those interruptions and someone asking
+something?
+
+And do less meetings? Why? Is it because nobody cares enough to write a
+meeting agenda to point what needs to be decided? Or maybe 'cause the frontend
+developers don't care enough about the problems the backend developers are
+facing and vice-versa?
+
+Would a meeting scheduled a week in advance an "interruption"?
+
+I can't see how interruptions can be a problem. Imagine this:
+
+This developer went though an onboarding when they joined the company, and
+they were shown the purpose of the company, they were shown the product the
+company sells and how it works, there were shown the product architecture,
+they were explained the reasons behind every solution applied, they were given
+time to discuss other solutions with their pairs, they were not put on a
+corner to explain every minute of their working day.
+
+With that, can you imagine that someone making a question about some part of
+the system while whoever is coding is in the middle of a function to
+frobnicate[^1] foo? Maybe they will need a bit time to find where they
+stopped, but as the solution was already discussed, and they know the purpose
+of the solution they are working, the interruption would do very little in
+their productivity.
+
+Unfortunately, in IT, we are seen as "machines" and most manufacturing
+techniques are applied directly without considering that we are people (or do
+you think "kanban" was born in IT and not inside the Toyota manufacturing
+plant?).
+
+A stopped machine is wasted money. Stopping production for preventive
+maintenance, without the machine being really broken, having to take it and
+check every part, is wasted money.
+
+And, unfortunately, when a developer is not "developing", they are seen as
+wasted money. And that's why simple stuff, like explaining why a system
+exists, what is the idea of the data flow inside the system and things like
+that are completely ignored: 'Cause the "machine" is not producing anything.
+
+And that's why, when the production is halted, productivity goes down.

content/thoughts/how-to-kill-developer-productivity.pt.md

@@ -0,0 +1,77 @@
++++
+title = "Como Matar a Produtividade de Desenvolvedores"
+date = 2020-07-20
+
+[taxonomies]
+tags = ["desenvolvedores", "programação", "ti", "onboarding", 
+"fluxo de dados", "arquitetura", "produtividade"]
++++
+
+Existem várias formas de não matar a produtividade de desenvolvedores num
+projeto. Infelizmente, as reais causas nunca são comentadas.
+
+<!-- more -->
+
+Recentemente vi mais um artigo de "como não matar a produtividades de
+desenvolvedores", que diz exatamente o que todos os artigos sobre como não
+matar a produtividade de desenvolvedores diz: Basicamente "Evite
+interrupções".
+
+Mas será que dá pra evitar interrupções mesmo? Não seria o "ping!" da
+cafeteira uma interrupção? Não seria a bexiga cheia uma interrupção? Não seria
+a campainha avisando que chegou a encomenda e/ou a tele-entrega uma
+interrupção?
+
+Qual é a diferença entre essas e alguém pedindo ajuda?
+
+E fazer menos reuniões? Por que? Porque ninguém se liga de fazer uma pauta de
+reunião para ter o que decidir? Ou será que é porque os desenvolvedores de
+frontend não dão a mínima para os problemas que o pessoal de backend está
+enfrentando e vice-versa?
+
+Seria uma reunião marcada com uma semana de antecedência uma "interrupção"?
+
+Eu não consigo ver que as interrupções em si são o problema. Imaginem o
+seguinte:
+
+Essa pessoa passou por um onboarding quando entrou na empresa, e foi
+apresentado ao propósito da mesma, foi apresentado ao produto que a empresa
+vende e como o produto funciona, foi apresentada à arquitetura do sistema, foi
+explicado o motivo de cada solução aplicada, foi dado tempo para discutir
+outras soluções com seus pares, não foi colocado contra a parede para explicar
+cada minuto de trabalho do seu dia.
+
+Dado isso, vocês conseguem imaginar que alguém fazendo uma pergunta sobre
+alguma parte do sistema enquanto quem está programando está no meio da função
+de frobnicar[^1] foo? Talvez perca algum tempo para ver em qual ponto parou,
+mas como a solução já foi discutida, e já se sabe o propósito da
+funcionalidade sendo introduzida, a interrupção vai afetar muito pouco o
+resultado final.
+
+Infelizmente, na área de TI, passamos muito tempo sendo vistos como "máquinas"
+e técnicas de produção são aplicadas diretamente sem considerar que somos
+pessoas (ou vocês acham que "kanban" nasceu no meio da TI mesmo e não dentro
+da fábrica da Toyota?). 
+
+Uma máquina parada é dinheiro perdido. Parar a produção para manutenção
+preventiva, sem que a máquina esteja realmente quebrada, tendo desmontar a
+mesma e verificar cada uma das partes, é dinheiro perdido.
+
+E, infelizmente, quando um programador não está "programando", é visto como
+dinheiro perdido. E por isso coisas básicas, como explicar o porque o sistema
+existe, qual a ideia do fluxo de dados dentro do mesmo, deixando que
+programadores parem e discutam soluções e coisas do tipo são completamente
+ignoradas: Porque a "máquina" não está produzindo.
+
+E, quando é preciso parar a produção, por qualquer motivo, a produtividade vai
+lá pra baixo.
+
+---
+
+[^1]: Eu não se tem alguma forma melhor de traduzir
+  [frobnicate](https://www.techopedia.com/definition/27996/frobnicate)
+
+
+<!-- 
+vim:spelllang=pt:
+-->