Continuando o desenvolvimento do "tu", "Time's Up!", em Rust.

O chassi de um fleet de microserviços é definido como as bibliotecas e frameworks que alguém deve usar quando está criando um novo microserviço.

Quem está começando com Python tende a usar range() quando precisa iterar sobre listas. Mas isso não é realmente necessário.

Quando estamos falando de um sistema, existe um ponto que precisamos discutir que é onde a "fonte da verdade" está. Em monolitos, a fonte da verdade está no armazenamento dos dados em si. Mas onde é que essa fonte fica em um sistema que é composto de múltiplas partes?

Se nós usássemos uma analogia para código sendo as palavras de um livro e o sistema sendo construído como o livro inteiro, o que seriam os testes unitários?

Hoje em dia, boa parte dos desenvolvedores utiliza alguma metodologia de testes. Mas o que são os testes? Para que servem? Qual o objetivo de se testar? Estamos testando as coisas certas?

As discussões anteriores que eu levantei sobre microserviços foram um prelúdio para uma coisa que eu não consegui uma solução perfeita: como é que microserviços se "curam" quando faltam dados?

Como eu estava comentando sobre artefatos em microserviços, eu acredito que esqueci de discutir um ponto importante: Como é que esses artefatos são "expelidos" do microserviço?

Projetar microserviços é um pouco complicado porque temos que pensar sobre as coisas que cada "domínio" vai ocupar. Uma discussão entre os desenvolvedores aqui sobre nossos projetos de microserviços me levou a repensar como pensar microserviços.

Resumo do GoodReads: Hegel foi um dos filósofos mais eruditos, com imenso conhecimento de arte, literatura, religião, filosofia, política e ciência, tanto de sua época como de épocas passadas. Criador do método dialético, que nas mãos de Marx daria origem à maior revolução desde a Revolução Francesa, admitia: "Apenas um homem me entende, e mesmo ele não consegue." Alguns críticos consideram que nesse ponto o filósofo exagerava. Terá esse homem existido realmente?