DEV Community: Uriel dos Santos Souza

Reactor e Proactor - Segredos do Event Loop do NodeJS

Uriel dos Santos Souza — Thu, 11 Dec 2025 19:28:16 +0000

Introdução

Esta é uma pequena introdução às soluções utilizadas no Node.js e nos navegadores para lidar com concorrência e operações de Entrada/Saída (E/S).

A História Rápida do Node.js

Quando o Node.js foi criado, ele utilizou o conceito do Event Loop em conjunto com E/S Não Bloqueante para evitar que as operações de entrada e saída travassem o sistema.

Em praticamente todos os aplicativos web modernos, temos muita E/S:

Interação com o banco de dados (solicitar, inserir ou atualizar registros).
Acesso a arquivos no disco rígido.
Comunicação em rede.

No modelo de programação síncrona, essas operações de E/S causam bloqueio, fazendo com que o programa espere (e fique inativo) até que a operação seja concluída. A solução para contornar isso é a adoção de um modelo assíncrono, implementado pelo Event Loop.

O Event Loop não foi inventado pelo pessoal do Node.js. O conceito por trás dele já existia em padrões arquiteturais como Reactor e Proactor. O Event Loop do Node.js atua como o componente central que implementa a lógica do padrão Reactor.

Entendendo o Padrão Reactor

O Padrão Reactor é um padrão de projeto de software fundamental usado em programação concorrente para lidar com eficiência com solicitações de serviço assíncronas que chegam de múltiplos clientes, utilizando um número limitado (muitas vezes, um único) de threads para a lógica principal de despacho.

O seu objetivo principal é permitir que um sistema (como um servidor de rede) gerencie múltiplas operações de E/S sem precisar de uma thread dedicada para cada conexão, melhorando a escalabilidade e o desempenho.

O padrão Reactor desacopla a detecção de que um evento está pronto (função do Desmultiplexador) do processamento real do evento (função do Manipulador).

Os principais componentes do Reactor são:

Identificadores (Handles): Recursos de E/S que são monitorados (como um socket de rede).
Desmultiplexador de Eventos Síncrono: O mecanismo de nível de OS (select(), epoll(), etc.) que bloqueia até que um ou mais identificadores estejam prontos para uma operação.
Reactor (Event Loop/Despachante): O componente principal que despacha o evento detectado para o Manipulador apropriado.
Manipulador de Eventos (Handler): O código da aplicação que processa o evento de forma não bloqueante.

Node.js: Arquitetura de Thread Única e Múltiplas Threads

Para lidar com solicitações da Web, existem duas arquiteturas concorrentes principais: baseadas em *threads* (uma thread por requisição) e orientadas a eventos (como o Reactor).

No Node.js, o código JavaScript do usuário roda sempre em uma única *thread. Esta é a **Thread Principal* (ou Main Thread V8). É por isso que o Node.js é frequentemente descrito como "de thread única".

No entanto, para lidar com E/S de forma assíncrona, o Node.js conta com a biblioteca libuv, que é quem implementa o Event Loop.

A libuv é responsável por:

I/O Não Bloqueante (via OS): Para a maioria das operações de rede, a libuv usa mecanismos assíncronos nativos do sistema operacional (como epoll no Linux). Isso não envolve o Thread Pool.
I/O Bloqueante (via Thread Pool): Para operações que são inerentemente bloqueantes (como a maioria das operações de sistema de arquivos - fs), a libuv as envia para um Pool de *Threads* (4 threads por padrão) para execução. Isso é totalmente transparente para o desenvolvedor JavaScript.

A Clarificação:

O Node.js é de thread única no que diz respeito à execução do código JavaScript.

O Node.js é multi-thread no que diz respeito à execução das tarefas de E/S pesadas, que são delegadas para o Thread Pool da libuv para não bloquear o Event Loop principal.

O Event Loop é o coração: A única thread de JS executa o loop de eventos. Quando uma operação de E/S (seja nativa ou do Thread Pool) termina, o callback é enfileirado e executado.

Reactor vs. Proactor: A Diferença Crucial

Ambos os padrões são modelos arquiteturais que lidam com concorrência de E/S, mas se diferenciam no momento em que o código da aplicação é invocado:

Característica	Padrão Reactor	Padrão Proactor
Invocação (O quê)	Prontidão para E/S (Readiness).	Conclusão da E/S (Completion).
Onde a E/S ocorre	O sistema notifica que os dados estão prontos. A aplicação deve ler/escrever os dados no handle.	O sistema operacional executa a operação de E/S (leitura/escrita) em segundo plano e notifica a aplicação com o resultado pronto.
Modelo de I/O	Síncrono (demultiplexação) + Assíncrono (despacho).	Totalmente Assíncrono (baseado em chamadas de conclusão).
*Exemplo (Web* Servers)**	Node.js (majoritariamente), Nginx.	Windows IOCP (nativamente), alguns frameworks de servidor de alta performance.

O Caso do Node.js (libuv)

A libuv adota uma abordagem híbrida com base no sistema operacional:

Node.js no Linux/macOS: É predominantemente Reactor.
Node.js no Windows: Utiliza o mecanismo nativo IOCP (I/O Completion Ports), que é a base para o Proactor.

É por isso que o Node.js é frequentemente chamado de modelo Reactor + "pseudo-Proactor" via *Thread Pool*.

Analogia do Restaurante:

Padrão Reactor (O Event Loop do Node.js) O garçom recebe o pedido (tarefa de E/S). Ele é notificado de que o bife está pronto para ser cortado/finalizado. A Thread Principal (ou uma thread do Thread Pool) executa os passos finais (corta o bife/processa a E/S) e o entrega.

PROACTOR: O garçom (Thread Principal/Event Loop) recebe o pedido e o delega. Ele é notificado de que o bife está completamente pronto e já na bandeja. A Thread Principal simplesmente entrega o resultado (o sistema operacional fez todo o trabalho de E/S)

Fila de Atendimento Telefônico (Call Center):

Padrão Reactor (O Event Loop do Node.js)
O Atendente (Reactor/Event Loop): É a única thread de execução. Ele tem fones de ouvido que monitoram 100 linhas (sockets) de uma vez.

O Trabalho do OS/Desmultiplexador: Quando a Linha 5 e a Linha 12 ficam prontas (alguém começou a falar/dados prontos), o sistema notifica o atendente.

Ação da Aplicação: O atendente para de monitorar momentaneamente e ouve a Linha 5 (lê os dados), processa o pedido rapidamente e desliga (executa o callback). O atendente não fica esperando na linha 5; ele só reage quando a linha está pronta.

Padrão Proactor
O Cliente (Aplicação): O cliente diz ao sistema telefônico: "Quando esta pessoa terminar de me dar todas as 5 informações que preciso, ligue-me de volta."

O Trabalho do OS/Sistema: O sistema (em segundo plano, com suas próprias threads) completa toda a interação (pega as 5 informações) e só então notifica a aplicação principal.

A Ação da Aplicação: A aplicação principal recebe uma notificação de conclusão que já contém todas as 5 informações.

REACTOR: "Avise-me quando puder fazer o trabalho." (Ênfase na prontidão.)

PROACTOR: "Avise-me quando o trabalho estiver concluído." (Ênfase na conclusão.)

As Fases do Event Loop do Node.js

O Event Loop divide seu ciclo de execução em fases, girando sobre o modelo Reactor para distribuir eventos:

Timers: Execução de callbacks de setTimeout e setInterval.
Pending Callbacks: Execução de callbacks de operações internas pós-E/S.
Idle, Prepare: Uso interno da libuv.
Poll (Sonda): Esta é a fase onde o Reactor realmente acontece.
- O libuv chama o Desmultiplexador de Eventos (ex: epoll_wait()).
- Ele espera que sockets fiquem prontos (read-ready / write-ready).
- Ao ser notificado, ele acorda e despacha os eventos para os handlers registrados.
Check: Execução de callbacks de setImmediate.
Close Callbacks: Execução de callbacks de fechamento (ex: socket.on('close')).

Conclusão: O ciclo inteiro é o Reactor (o despachante) rodando e distribuindo eventos. Mas a fase Poll é a parte que implementa o Desmultiplexador de Eventos Síncrono (a espera pela prontidão da E/S) do Padrão Reactor.

Em resumo, o sucesso do Node.js reside na adoção do padrão Reactor (e uma implementação híbrida com o Proactor em certas plataformas), garantindo que a Thread Principal do JavaScript nunca bloqueie, permitindo uma escalabilidade enorme com baixo consumo de memória.

Fontes para aprofundamento do conteúdo!
https://betterprogramming.pub/scalable-concurrency-meet-non-blocking-i-o-edb6b39c59d7

https://subscription.packtpub.com/book/web-development/9781783287314/1/ch01lvl1sec09/the-reactor-pattern

http://didawiki.cli.di.unipi.it/lib/exe/fetch.php/magistraleinformatica/tdp/tpd_reactor_proactor.pdf

https://indico.cern.ch/event/282910/contributions/645355/attachments/521441/719267/efficient_parallel_IO_on_multicore_arch2.pdf

https://stackoverflow.com/questions/56739934/is-nodejs-representing-reactor-or-proactor-design-pattern

https://stackoverflow.com/questions/9138294/what-is-the-difference-between-event-driven-model-and-reactor-pattern

https://stackoverflow.com/questions/61163161/how-does-the-libuv-implementation-of-non-blockingness-work-exactly

https://en.wikipedia.org/wiki/Reactor_pattern

https://en.wikipedia.org/wiki/Proactor_pattern

https://tusharf5.com/posts/node-design-patterns-reactor-pattern/

https://progressivecoder.com/nodejs-reactor-pattern-event-loop/

https://medium.com/@mohamed-khattab/demystifying-the-reactor-design-pattern-in-node-js-a8aabd73a315

https://www.youtube.com/watch?v=Vm5l8zH4hOE

https://www.artima.com/articles/comparing-two-high-performance-io-design-patterns

Peculiaridades do JS. Que não são erros! Nem esquisitice! - conversão implícita de tipos

Uriel dos Santos Souza — Wed, 11 Oct 2023 16:14:21 +0000

Todos nós javascripteiros sabemos que nossa linguagem
tem conversão implícita de tipos.

O que não sabemos, ou pelo menos eu não sabia é que
antes da sua versão final ela não tinha.

Mocha(JS) originalmente não tinha conversão implícita de tipo, mas os usuários solicitaram que Eich adicionasse isso a 1.0. Ele lamenta profundamente isso.

fonte do que estou dizendo

https://www.youtube.com/watch?time_continue=2503&v=krB0enBeSiE&embeds_referring_euri=https%3A%2F%2Ftwitter.com%2F&source_ve_path=MjM4NTE&feature=emb_title

https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today/#:~:text=notorious

Se a conversão de tipo é uma coisa que você odeia!
Saiba que foi um pedido da comunidade de usuários da época.

Podemos aprender que o que os usuários/comunidade querem ou acham bom pode mudar com o tempo.

Hoje ferramentas fazem sucesso, linguagens incorporam funcionalidades. Em alguns anos isso pode ser odiado.

O que é bom hoje pra uma linguagem ter pode não ser bom em 30 anos!

Egoless Crafting(criação sem ego) para software: os princípios

Uriel dos Santos Souza — Sat, 23 Sep 2023 14:05:13 +0000

A catarse intelectual e afetiva consiste em livrar-se dos preconceitos e opiniões.

Em 2009, o Software Craftsmanship Manifesto foi publicado como uma extensão do Manifesto Ágil , para corrigir o desvio de parte do movimento Ágil em reconhecer a importância da excelência técnica.

Conheça seus príncipios!

1- Você não é suas práticas

Nenhuma prática é perfeita e você tem que aceitar que alguém possa criticar as práticas que você usa. A crítica à sua prática não é uma crítica a si mesmo. Tenha em mente que as práticas evoluem, adaptam-se e eventualmente tornam-se obsoletas quando as suas limitações impedem a resposta aos desafios tecnológicos em constante mudança.

2 - Não seja um sobrevivente

Só porque você aplicou com sucesso uma prática em uma experiência anterior, não significa que ela funcionará em todos os casos: o contexto é importante. Cada contexto é diferente, os parâmetros que garantiram este sucesso anterior podem não existir em todas as situações.

Na maioria das vezes, esquecemos que as Pessoas são importantes no contexto e essa é a variável mais importante que você precisa considerar. Você deve identificar as dores contra as quais as pessoas estão lutando. Só então você poderá sugerir uma prática de acordo com seus benefícios em relação a essas dores. Você deve aceitar e reconhecer que cada equipe evolui em seu próprio ritmo, equilibrando obstáculos operacionais e curvas de aprendizado.

O que salvou você pode não funcionar para os outros, então não force. Considere o fato de que você pode estar fazendo isso apenas para se convencer de que fez a escolha certa naquele momento.

3 - Desafie os resultados, não force a sua opinião

Quando você é solicitado a revisar uma solução,** é tentador tentar moldá-la de acordo com sua preferência.** Sempre existem várias soluções para o mesmo problema. Não deixe que suas preferências pessoais tragam entropia improdutiva às discussões.

Durante uma revisão, sempre que outra implementação vier à mente, tente se perguntar se ambas as soluções apresentam os mesmos benefícios. Caso contrário, comece por melhorar a primeira solução na sua lógica antes de propor uma implementação alternativa, sem esquecer de considerar as possíveis desvantagens.

Repita o procedimento acima, substituindo “implementação” por “decisão” e “prática”.

4 - Software não se trata apenas de código

Software bem elaborado é um valor apresentado no Manifesto de Artesanato de Software. Infelizmente, alguns aspirantes a artesãos de software parecem se importar apenas com o código. Isto se deve em parte ao fato de que as práticas mais populares na caixa de ferramentas de elaboração são centradas no código – por exemplo, Código Limpo, Desenvolvimento Orientado a Testes ou Katas.

No entanto, código não é software. Ao escrever código, você apenas faz suposições sobre o que os usuários realmente precisam. Essas hipóteses são validadas (ou não) quando os usuários interagem com seu ambiente de produção: então a produção importa. A entrega frequente à produção é a única maneira de agregar valor de forma constante. Adotar uma prática como o Desenvolvimento Orientado a Testes terá um impacto muito limitado na qualidade do seu produto, se você receber feedback sobre o que está construindo apenas uma ou duas vezes por ano.
**
Não somos pagos para criar software apenas por diversão. Nosso know-how técnico deve servir o negócio.** Portanto, construir parcerias produtivas com nossos especialistas em domínio é necessário para melhor atender às necessidades de nossos usuários: O Domínio Empresarial é importante .

“Não é o conhecimento das partes interessadas, mas a ignorância dos desenvolvedores que é implantada na produção”. Alberto Brandolini

5 - O software é produzido por uma organização, não por indivíduos

Existe uma falsa crença comum que afirma que os desenvolvedores produzem software, o que leva a uma espécie de Síndrome do Herói. Conforme afirmado acima, as habilidades de desenvolvimento não são suficientes para construir software. É a sua organização multidisciplinar que produz software.

A influência da estrutura organizacional na qualidade do software: um estudo de caso empírico (Nagappan, Murphy, Basili - 2008) demonstrou que a qualidade da estrutura organizacional era um melhor preditor de propensão a falhas do que as métricas tradicionais - como cobertura de código, complexidade de código ou Code Churn – no caso do Windows Vista.

Não importa quão habilidoso você seja, a comunicação e a colaboração sempre terão um impacto maior no sistema projetado e você não pode projetar um sistema sozinho. Seja curioso e preste atenção e respeito aos demais atores envolvidos na construção do software: Design e Organização importam.

6 - Software Craftsmanship diz respeito a todos, não apenas aos artesãos

Pode ser muito tentador ficar entre artesãos para evitar o trabalho de convencer. No entanto, esta filosofia gera uma auto-segregação e prende os artesãos numa bolha deletéria de meios que nunca são desafiados.

A caixa de ferramentas de elaboração rapidamente se tornará obsoleta sem ser questionada por visões externas e sem se beneficiar da experiência complementar de toda a comunidade de profissionais de software. A sua capacidade de responder a novos desafios será bastante limitada.

É também por isso que o manifesto tem como subtítulo a elevação da fasquia: o objetivo é ajudar toda a comunidade profissional. Ao ajudar, aprendemos e descobrimos contextos que fogem às nossas formas comuns e diferentes de pensar.

Ao trabalhar com pessoas de fora do movimento, tenha em mente que nunca se deve vender uma prática como uma injunção de meios, mas sempre convencer pelos benefícios que esta prática traz. Em outras palavras, se você “vender” o Domain-Driven Design explicando que é o melhor método no mercado para modelar um domínio de negócios, então você o está “vendendo” mal.

As pessoas tentam fazer o seu melhor em contextos onde são pressionadas a chegar a um acordo pelas autoridades locais. Portanto, não julgue as deficiências do que foi feito. Identifique as reais dores dessas pessoas e veja como você pode ajudá-las. No entanto, lembre-se de que você deve fornecer ajuda, nunca infligir ajuda .

7 - Não carregue a carga(alusão ao culto a carga)

Só porque você reproduz as práticas, ferramentas e processos de outra pessoa não significa que alcançará o mesmo sucesso. Como mencionado acima, o contexto é importante. Essa pessoa “outra pessoa” pode ter meios, restrições ou facilitadores que você não tem.

Cuidado, sua atividade não é igual à das grandes empresas de TI. S*ó porque o Google usa o Kubernetes não significa que você precisa do Kubernetes* e que ele atenderá às suas necessidades.

Sempre analise o espaço do problema e defina suas necessidades antes de pensar em uma solução. Não deixe que o hype e as figuras de autoridade lhe ditem o que fazer.

8 -O treinador de Usain Bolt não corre mais rápido que Usain Bolt

Ter mais experiência ou ser coach não faz de você um desenvolvedor melhor do que as pessoas que você ajuda. Você aprenderá coisas com seus pupilos, e eles podem até ser melhores do que você em alguns aspectos. E tudo bem: ninguém espera que você seja o melhor em tudo. Você deve permitir que os outros expressem seu potencial e ajudá-los a fazê-lo.

Não use sua autoridade para impor sua opinião. Software Craftsmanship é uma comunidade de realizadores. Não construa para si uma torre de marfim da qual lançará seu conhecimento “acima do solo” em relação à realidade da área. Da mesma forma, tome cuidado com os pregadores em sua própria torre. Lidere pelo exemplo e pela ação, organize sessões de programação em pares ou mob com pessoas onde você interage durante a construção do software.

Respeite e trate os outros como iguais seja qual for o seu nível para que a transmissão do conhecimento possa ser feita de acordo com uma abordagem horizontal, evite a abordagem vertical que tem a infeliz tendência de criar cultos. Ouvir e humildade são essenciais para construir uma parceria produtiva e de confiança. Desenvolvimento de software é trabalho em equipe.

9 - Ferramentas e práticas não são uma garantia

Software Craftsmanship é escolher a melhor ferramenta para a situação certa. A desvantagem de ferramentas poderosas é que você acaba pensando que elas são suficientes para garantir o sucesso. Ferramentas e práticas recomendadas são modelos criados para melhor atender a um caso de uso específico. Às vezes, esses modelos podem ser aplicados com sucesso a novos casos de uso para os quais não foram originalmente pensados, com algumas adaptações.

Mas todos os modelos têm os seus limites: nunca serão adequados para todas as situações existentes e nem sempre serão igualmente eficazes. Não existe Bala de Prata . Além disso, os limites e eficiências de cada uma das nossas ferramentas são apenas muito mal documentados cientificamente (através de estudos rigorosos).

É por isso que é preciso saber deixar espaço para a experimentação de novas ferramentas, sejam elas “aprovadas pelo Craft” ou não. Mais uma vez, é mais importante concentrar-se nos resultados das práticas implementadas do que nos meios. Esta é a única maneira de inovar .

Tenha em mente que não há menção a nenhuma ferramenta como Desenvolvimento Orientado a Testes ou Kata no Manifesto de Artesanato de Software. Usá-los não fará de você um artesão, assim como não usá-los não desqualifica alguém de ser um artesão.

10 - Não seja um crente, a dúvida impulsiona a melhoria

Quando alguém é convencido pelos méritos de um movimento, facilmente se transforma em evangelista. Mas esta postura pode rapidamente tornar-se uma prisão de crença, mantendo a sua própria escalada de compromisso com o movimento ao embarcar toda uma estrutura rumo a um fracasso programado, ao mesmo tempo que cria exclusão à sua volta.

No entanto, uma crença firme em algo é muitas vezes vista como um ponto forte:

Quando alguém acredita firmemente que o artesanato envolve ferramentas, ele cria fantoches.
Quando alguém acredita firmemente que o artesanato tem tudo a ver com meios, isso gera cultos à Carga.
Quando alguém acredita firmemente que elaborar tem a ver com gols, cai na obsessão por marcar.
E quando alguém acredita firmemente que o artesanato é uma paixão, torna-se um guardião.

O dogmatismo é um veneno que trata a dúvida como uma fraqueza. Mas a dúvida é na verdade um vetor de melhoria, através do questionamento. O questionamento sempre terá um resultado positivo: seja destacando um ponto fraco de uma prática que poderia ser melhorado, seja melhorando a compreensão de quem expressa a dúvida. A dúvida é um pilar disruptivo fundamental do pensamento científico.

Concluindo o artesanato sem ego

Egoless Crafting tenta reorientar o Software Craftsmanship, não em práticas, ferramentas ou código, mas em comportamentos humanos. Devem refletir os valores do manifesto. Ou seja, a Cultura importa e é a única forma de corrigir os excessos que hoje podemos presenciar #egolesscrafting.

“A cultura come a estratégia no café da manhã.” Peter Drucker

Original > https://egolesscrafting.org/

O objeto Atomics do JS uma introdução, multithreading e memória!

Uriel dos Santos Souza — Sat, 15 Jul 2023 14:35:43 +0000

Nosso querido JavaScript é single threaded(como todos sempre pensamos, embora isso não esteja na especificação da linguagem JS).
Java Script só pode executar uma coisa por ve sendo single threaded, guarde isso, isso é importante!

Portanto, se uma tarefa de execução longa bloquear o encadeamento principal do navegador, o navegador terá dificuldade para renderizar.

Por exemplo, se fôssemos percorrer e executar operações em uma grande estrutura de dados,
ou criar um loop simples muito grande.
Isso poderia fazer com que a renderização congelasse. Enquanto o loop não terminasse, ou enquanto o algoritmo estivesse percorrendo a grande estrutura de dados, não da pra fazer nada, apenas olhar e esperar.

Esse é um problema de single threaded.
Só da pra fazer uma coisa por vez e se ela toma muito tempo, não da pra fazer mais nada!

Não iremos falar sobre callbacks e promises neste texto.

Uma das soluções para esse problema é usar Web Workers.

Web Workers são mecanismos que permitem que uma operação de um dado script seja executado em uma thread diferente da thread principal da aplicação Web. Permitindo que cálculos laboriosos sejam processados sem que ocorra bloqueio da thread principal (geralmente associado à interface).
Fonte > mdn.

Sabemos que js é single threaded.
Com o tempo as aplicações no navegador estavam ficando cada vez mais exigentes.
Então resolveram trazer os web Workers para nos ajudar!

Agora aquele loop gigante pode ir pra outro thread e deixa nossa tela principal linda e leve sem ninguém atrapalhar!

Os Web Workers permitem a execução paralela no contexto do navegador.

No entanto como tudo em tecnologia, os Web Workers têm suas desvantagens; por exemplo, há um custo de transferência de dados de e para o thread Worker. Toda transferência é feita via postMessage.

O que é postMessage:

Window: postMessage() method - Web APIs | MDN

The window.postMessage() method safely enables cross-origin communication between Window objects; e.g., between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.

developer.mozilla.org

O navegador usa o algoritmo structured clone

The structured clone algorithm - Web APIs | MDN

The structured clone algorithm copies complex JavaScript objects. It is used internally when invoking structuredClone(), to transfer data between Workers via postMessage(), storing objects with IndexedDB, or copying objects for other APIs.

developer.mozilla.org

Para duplicar um objeto, ou seja duplicação dos mesmos dados na memoria. Esse custo, dependendo das circunstâncias, pode superar o benefício da transferência para o thread Worker.

Você também pode transferir array Buffer!

O que é array Buffer:

ArrayBuffer - JavaScript | MDN

O objeto ArrayBuffer é um tipo de dado usado para representar um genérico, buffer de dados binários de tamanho fixo. Você não pode manipular diretamente os conteúdos de um ArrayBuffer; em vez disso, você cria um objeto ArrayBufferView que representa o buffer em um formato específico, e usa para ler e escrever os conteúdos do buffer.

developer.mozilla.org

Mas temos o problema, assim que for transferido o main perde ele.
É melhor que postMessage sim.

Arraybuffer objeto transferivel:

Transferable objects - Web APIs | MDN

Transferable objects are objects that own resources that can be transferred from one context to another, ensuring that the resources are only available in one context at a time. Following a transfer, the original object is no longer usable; it no longer points to the transferred resource, and any attempt to read or write the object will throw an exception.

developer.mozilla.org

Mas nosso foco não é array buffer também!

Você tem uma outra opção que é a Broadcast Channel API

O que é Broadcast Channel API:

Broadcast Channel API - Web APIs | MDN

The Broadcast Channel API allows basic communication between browsing contexts (that is, windows, tabs, frames, or iframes) and workers on the same origin.

developer.mozilla.org

Mas ela tem o mesmo problema de mensagens!
E usa o mesmo algoritmo de clone o structured clone e claro usa PostMessage!

E se pudéssemos evitar a cópia ou transferência de dados?
Uma maneira de contornar esses problemas é aproveitar SharedArrayBuffer.

A partir daqui podemos afirmar que JavaScript não é mais single threaded por padrão!

Web workers não fazem parte do javascript em si. Não estão na especificação da linguagem.
Mas estão em outras especificações(que não vem ao caso agora)

Para desenvolvedores de JavaScript, essa construção nos permite criar pedaços de memoria compartilhada. Em vez de copiar os dados do thread principal para o Worker e vice-versa, podemos atualizar a mesma memória compartilhada de ambos os lados.

// 
const length = 10;
 // Criando o tamanho do nosso buffer
const size = Int32Array.BYTES_PER_ELEMENT * length;
 // Criando o buffer com 10 inteiros 
const sharedBuffer = new SharedArrayBuffer(size);
const sharedArray = new Int32Array(sharedBuffer);

O que é Int32Array:

Int32Array - JavaScript | MDN

The Int32Array typed array represents an array of twos-complement 32-bit signed integers in the platform byte order. If control over byte order is needed, use DataView instead. The contents are initialized to 0. Once established, you can reference elements in the array using the object's methods, or using standard array index syntax (that is, using bracket notation).

developer.mozilla.org

O que é sharedarraybuffer:

Esclarecimentos sobre a mensagem do objeto SharedArrayBuffer | Blog da Central da Pesquisa Google | Google for Developers

developers.google.com

Agora temos um pedaço de memória que pode ser compartilhado. Ou seja, o thread principal e os web workers podem acessar esse mesmo local juntos!

Isso é muito bom, economiza memória!
Mas como tudo em tecnologia, tem desvantagens!

Imagina o seguinte: Temos 3 ou mais Web Workers além do thread principal acessando um mesmo local de memória. Isso vai dar errado.
Muito errado. Podemos ter uma condição de corrida. Todos disputando o mesmo lugar ou termos um problema de atualizar 2 vezes o mesmo lugar com as mesmas informações.
Ou seja 2 workers podem fazer o mesmo trabalho ao mesmo tempo e isso é desperdício.

O que é condição de corrida:

A race condition or race hazard is the condition of an electronics, software, or other system where the system's substantive behavior is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when one or more of the possible behaviors is undesirable.

View on Wikipedia

Então criaram o objeto Atomics.

As operações atômicas garantem que tenhamos uma maneira padronizada de ler e gravar dados em uma ordem previsível

Atomics gerencia o acesso de todo mundo ao pedaço de memória, assim impedindo condições de corrida, trabalhos desperdiçado, etc.

O que é Atomics:

Atomics - JavaScript | MDN

The Atomics namespace object contains static methods for carrying out atomic operations. They are used with SharedArrayBuffer and ArrayBuffer objects.

developer.mozilla.org

// main.js
const worker = new Worker('worker.js');
const length = 10;
const size = Int32Array.BYTES_PER_ELEMENT * length;

const sharedBuffer = new SharedArrayBuffer(size);
const sharedArray = new Int32Array(sharedBuffer);
for (let i = 0; i < 10; i++) {
    Atomics.store(sharedArray, i, 0);
}
worker.postMessage(sharedBuffer);

Acessando o dados no worker

// worker.js
self.addEventListener('message', (event) => {
    const sharedArray = new Int32Array(event.data);
    for (let i = 0; i < 10; i++) {
        const arrayValue = Atomics.load(sharedArray, i);
        console.log(`The item at array index ${i} is ${arrayValue}`);
    }
}, false);

E se quiséssemos atualizar a matriz do trabalhador? Temos duas opções para essas atualizações usando o Atomics. Podemos usar storeo que vimos antes, ou podemos usar exchange. A diferença aqui é que storeretorna o valor que é armazenado e exchangeretorna o valor que é substituído. Vamos ver como isso funciona na prática:

// worker.js
self.addEventListener('message', (event) => {
    const sharedArray = new Int32Array(event.data);
    for (let i = 0; i < 10; i++) {
        if (i%2 === 0) {
            const storedValue = Atomics.store(sharedArray, i, 1);
            console.log(`The item at array index ${i} is now ${storedValue}`);
        } else {
            const exchangedValue = Atomics.exchange(sharedArray, i, 2);
            console.log(`The item at array index ${i} was ${exchangedValue}, now 2`);
        }
    }
}, false);

Agora podemos ler e atualizar a matriz do thread principal e do thread de trabalho. Atomics tem alguns outros métodos que podemos usar a nosso favor para gerenciar nossos novos arrays compartilhados. Dois dos métodos mais úteis são waite wake. waitnos permite esperar uma mudança em um índice de array e então continuar com as operações. Na prática, isso pode parecer algo assim no lado do trabalhador:

self.addEventListener('message', (event) => {
    const sharedArray = new Int32Array(event.data);
    const arrayIndex = 0;
    const expectedStoredValue = 50;
    // An optional 4th argument can be passed which is a timeout
    Atomics.wait(sharedArray, arrayIndex, expectedStoredValue);
    // Log the new value
    console.log(Atomics.load(sharedArray, arrayIndex));
}, false);

Aqui estamos esperando uma alteração em arrayIndex0, onde o valor armazenado esperado é 50. Então, podemos dizer a ele para acordar do thread principal quando alterarmos o valor no índice:

const newArrayValue = 100;
Atomics.store(sharedArray, 0, newArrayValue);
// The index that is being waited on
const arrayIndex = 0;
// The first agent waiting on the value
const queuePos = 1;
Atomics.wake(sharedArray, arrayIndex, queuePos);

Outras funções são fornecidas por conveniência, como adde subque adicionam ou subtraem do índice da matriz, respectivamente. Se você estiver interessado em operações bit a bit , algumas delas são fornecidas, incluindo or, ande xor.

Podemos ver que atomics podemos evitar condições de corrida e fazer atualizações previsíveis em um array usando os métodos de Atomics.

Para usar strings, precisamos convertê-las em uma representação numérica, por exemplo, um padrão conhecido para codificação como UTF-16.

function sharedArrayBufferToUtf16String(buf) {
    const array = new Uint16Array(buf);
    return String.fromCharCode.apply(null, array);
}

function utf16StringToSharedArrayBuffer(str) {
    // 2 bytes for each char
    const bytes = str.length *2;
    const buffer = new SharedArrayBuffer(bytes);
    const arrayBuffer = new Uint16Array(buffer);
    for (let i = 0, strLen = str.length; i < strLen; i++) {
        arrayBuffer[i] = str.charCodeAt(i);
    }
    return { array: arrayBuffer, buffer: buffer };
}

const exampleString = "Hello world, this is an example string!";
const sharedArrayBuffer = utf16StringToSharedArrayBuffer(exampleString).buffer;
const backToString = sharedArrayBufferToUtf16String(sharedArrayBuffer);

Todos os códigos são retirados deste texto:

The Return of SharedArrayBuffers and Atomics - SitePen

See how we leverage SharedArrayBuffers to share memory between various thread contexts while avoiding race conditions using the Atomics methods.

sitepen.com

Fiz uma pequena introdução ao objeto Atomics
lembrando que tudo isso *funciona no Node também! *
Se você quiser saber mais basta ler as fontes:

https://www.sitepen.com/blog/the-return-of-sharedarraybuffers-and-atomics

https://dev.to/feezyhendrix/worker-threads-in-node-js-2ikh

https://exploringjs.com/es2016-es2017/ch_shared-array-buffer.html

https://blogtitle.github.io/using-javascript-sharedarraybuffers-and-atomics/

https://blog.logrocket.com/understanding-sharedarraybuffer-and-cross-origin-isolation/

https://www.tutorialspoint.com/what-is-the-use-of-atomics-in-javascript

https://webreflection.medium.com/about-sharedarraybuffer-atomics-87f97ddfc098

https://www.geeksforgeeks.org/atomics-in-javascript/

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics

https://www.youtube.com/watch?v=2w7Ewkpftd4

Actor Model, modelo do ator em programação! Você conhece?

Uriel dos Santos Souza — Tue, 20 Jun 2023 16:18:57 +0000

O Actor Model é um modelo matemático para sistemas concorrentes em ciência da computação. Ou em outras palavras: o modelo de ator fornece regras e primitivas para lidar com o paralelismo.

Actor Model é um modelo conceitual de computação concorrente, surgiu em 1973.

As regras, que normalmente são impostas pela linguagem ERLANG, são as seguintes:

Tudo (não primitivo) é um ator
Um ator tem estado local (“variáveis”)
Um ator é uma entidade computacional (“processo”) que executa sequencialmente (“single-threaded”)
Um ator tem um endereço (no sentido de caixa de correio, não de memória)
Um ator pode receber mensagens e reagir a elas por:
- Mutando seu estado local
- Criando novos atores
- Envio de mensagens para outros atores de forma assíncrona usando seus endereços

Embora cada ator seja executado sequencialmente, ou seja, apenas uma mensagem é processada por um ator por vez, dois atores podem muito bem ser executados em paralelo.

As implementações mais famosas para o Actor Model são Akka & Erlang. Falaramos mais de Erlang.

Os atores são leves e é muito fácil criar milhões deles, pois consomem menos recursos do que os Threads.

O estado privado do ator só pode ser alterado pelo processamento de uma mensagem, ele pode manipular apenas uma mensagem por vez e eles funcionam de forma assíncrona, isso significa que um ator nunca espera por uma resposta de outro ator.

No cenário distribuído, é possível que os Atores estejam em máquinas diferentes, portanto, eles se comunicam com endereços com mensagens, um endereço pode ser um endereço local ou um endereço remoto.

A linguagem Erlang, construída por Joe Armstrong na Ericson, ainda é usada hoje para sistemas extremamente escaláveis e tolerantes a falhas.

Por exemplo, os backbones de sua conexão LTE são escritos em Erlang e também são usados para produtos como WhatsApp ou usados por empresas como Facebook e Amazon.

Actor Model não precisa de nenhuma primitiva de sincronização como mutexes ou semáforos. Nenhum ator pode modificar o estado local de outro ator e cada ator em si é *single-threaded. *

Qualquer recurso exigido por vários atores deve ter seu próprio ator designado que gerencia o acesso a esse recurso. Todos os outros atores podem solicitar operações a serem executadas enviando uma mensagem ao ator gestor.

"Um ator é a unidade primitiva de computação. É aquilo que recebe uma mensagem e faz algum tipo de cálculo com base nela."

Basicamente como Alan Kays definia OOP.

A ideia é muito parecida com a que temos nas linguagens orientadas a objetos: um objeto recebe uma mensagem (uma chamada de método) e faz algo dependendo de qual mensagem ele recebe (qual método estamos chamando).

A principal diferença é que os atores estão completamente isolados **uns dos outros e **nunca compartilharão a memória. Também vale a pena notar que um ator pode manter um estado privado que nunca pode ser alterado diretamente por outro ator.

Uma diferença importante entre passar mensagens e chamar métodos é que as mensagens não têm valor de retorno. Ao enviar uma mensagem, um ator delega trabalho a outro ator, se esperasse um valor de retorno, o ator remetente precisaria bloquear ou executar o trabalho do outro ator no mesmo thread. Em vez disso, o ator receptor entrega os resultados em uma mensagem de resposta.

Os atores reagem às mensagens da mesma forma que os objetos “reagem” aos métodos invocados neles. A diferença é que, em vez de vários encadeamentos “projetando” em nosso ator e causando estragos no estado interno e invariantes, os atores executam independentemente dos remetentes de uma mensagem e reagem às mensagens recebidas sequencialmente, uma de cada vez. Enquanto cada ator processa as mensagens enviadas a ele sequencialmente, diferentes atores trabalham simultaneamente uns com os outros para que um sistema de ator possa processar tantas mensagens simultaneamente quantas o hardware suportar.

No modelo de ator tudo é um ator e eles precisam ter endereços para que um ator possa enviar uma mensagem para outro.

Atores têm caixas de correio
É importante entender que, embora vários atores possam ser executados ao mesmo tempo, um ator processará uma determinada mensagem sequencialmente. Isso significa que se você enviar 3 mensagens para o mesmo ator, ele executará apenas uma de cada vez. Para que essas 3 mensagens sejam executadas simultaneamente, você precisa criar 3 atores e enviar uma mensagem para cada um.

As mensagens são enviadas de forma assíncrona para um ator, que precisa armazená-las em algum lugar enquanto processa outra mensagem. A caixa de correio é o local onde essas mensagens são armazenadas.

Os atores se comunicam entre si enviando mensagens assíncronas. Essas mensagens são armazenadas nas caixas de correio de outros atores até serem processadas.

O uso de passagem de mensagens evita travamentos e bloqueios.

Em vez de chamar métodos(oop), os atores enviam mensagens uns aos outros. O envio de uma mensagem não transfere o thread de execução do remetente para o destino. Um ator pode enviar uma mensagem e continuar sem bloquear. Portanto, ele pode realizar mais na mesma quantidade de tempo.

O que os atores fazem
Quando um ator recebe uma mensagem, ele pode fazer uma destas 3 coisas:

Criar mais atores
Enviar mensagens para outros atores
Designar o que fazer com a próxima mensagem

Um ator pode manter um estado privado.

“Designar o que fazer com a próxima mensagem”

significa basicamente definir como será esse estado para a próxima mensagem que receber. Ou, mais claramente, é como os atores mudam de estado.

Vamos imaginar que temos um ator que se comporta como uma calculadora e que seu estado inicial é simplesmente o número 0. Quando este ator recebe a mensagem add(1), ao invés de mudar seu estado original, ele designa que para a próxima mensagem que receber, o estado será 1.

Tolerância a erro

Erlang introduziu a filosofia “deixe travar”. **A ideia é que você não precise programar defensivamente, tentando antecipar todos os possíveis problemas que podem acontecer e encontrar uma maneira de lidar com eles, **simplesmente porque não há como pensar em cada ponto de falha.

O que Erlang faz é simplesmente deixá-lo travar, mas fazer com que esse código crítico seja supervisionado por alguém cuja única responsabilidade seja saber o que fazer quando esse travamento acontecer(como redefinir essa unidade de código para um estado estável), e o que torna tudo isso possível é o modelo de ator.

Todo código roda dentro de um process(é basicamente assim que Erlang chama seus atores).
Isse process é completamente isolado, o que significa que seu estado não influenciará nenhum outro process. Temos um supervisor, que é basicamente outro process(tudo é ator, lembra?), que será avisado quando o supervisionado process travar e poderá fazer algo a respeito.

Isso possibilita a criação de sistemas que se “autocuram”, o que significa que se um ator chegar a um estado excepcional e travar, por qualquer motivo, um supervisor pode fazer algo a respeito para tentar colocá-lo em um estado consistente novamente (e há existem várias estratégias para fazer isso, sendo a mais comum apenas reiniciar o ator com seu estado inicial).

Distribuição

Outro aspecto interessante do modelo de ator é que não importa se o ator para o qual estou enviando uma mensagem está sendo executado localmente ou em outro nó.

Pense nisso, se um ator é apenas esta unidade de código com uma caixa de correio e um estado interno, e apenas responde a mensagens, quem se importa em qual máquina ele está realmente rodando? Contanto que possamos fazer a mensagem chegar lá, estamos bem.

Isso nos permite criar sistemas que aproveitam vários computadores e nos ajudam a recuperar se um deles falhar.

Prós do modelo de ator

Fácil de escalar
Tolerante a falhas
Nenhum estado compartilhado

Contras do modelo de ator

A caixa de correio pode transbordar
Suscetível a impasses

O Actor Model é bem conceituado e faz todo o sentido usar o Actor Model se alguém estiver projetando sistemas concorrentes.

Fontes:
https://surma.dev/things/actormodel/
https://www.brianstorti.com/the-actor-model/
https://en.wikipedia.org/wiki/Actor_model
https://eximia.co/reactive-messaging-patterns-with-the-actor-model/
https://medium.com/@KtheAgent/actor-model-in-nutshell-d13c0f81c8c7
https://doc.akka.io/docs/akka/current/typed/guide/actors-intro.html
https://getakka.net/articles/intro/what-are-actors.html
https://s3-sa-east-1.amazonaws.com/thedevconf/presentations/TDC2019SP/dotnet/UJJ-3987_2019-07-17T025204_Introdu%C3%A7%C3%A3o%20ao%20Actor%20Model%20com%20Microsoft%20Orleans.pdf

Escreva código que seja fácil de excluir e fácil de depurar também!

Uriel dos Santos Souza — Sun, 07 May 2023 12:53:31 +0000

Código depuravel é um código que não é mais esperto que você. Alguns códigos são um pouco mais difíceis de depurar do que outros: código com comportamento oculto, tratamento de erros insatisfatório, ambiguidade, muito pouca ou muita estrutura ou código que está no meio de ser alterado. Em um projeto grande o suficiente, você eventualmente encontrará um código que não entende.

Em um projeto antigo o suficiente, você descobrirá o código que esqueceu que escreveu - e se não fosse pelos logs de confirmação, você juraria que era outra pessoa. À medida que um projeto aumenta de tamanho, fica mais difícil lembrar o que cada parte do código faz, mais difícil ainda quando o código não faz o que deveria. Quando se trata de alterar o código que você não entende, você é forçado a aprender da maneira mais difícil: depuração.

Escrever um código fácil de depurar começa com a percepção de que você não se lembrará de nada sobre o código posteriormente.

Regra 0: Um bom código tem falhas óbvias.
Muitos vendedores de metodologias argumentaram que a maneira de escrever um código compreensível é escrever um código limpo. O problema é que “limpo” tem um significado altamente contextual. O código limpo pode ser codificado em um sistema e, às vezes, um hack sujo pode ser escrito de uma maneira fácil de desativar. Às vezes, o código está limpo porque a sujeira foi enviada para outro lugar. Código bom não é necessariamente código limpo.

O código estar limpo ou sujo tem mais a ver com quanto orgulho ou constrangimento o desenvolvedor sente no código, do que com a facilidade de mantê-lo ou alterá-lo. Em vez de limpo, queremos um código enfadonho onde a mudança é óbvia — descobri que é mais fácil fazer com que as pessoas contribuam para uma base de código quando o fruto mais fácil foi deixado para outros coletarem. O melhor código pode ser qualquer coisa que você possa ver e aprender rapidamente.

Código que não tenta fazer um problema feio parecer bom, ou um problema chato parecer interessante.
Código onde as falhas são óbvias e o comportamento é claro, em vez de código sem falhas óbvias e comportamentos sutis.
Código que documenta onde fica aquém da perfeição, em vez de almejar ser perfeito.
Código com comportamento tão óbvio que qualquer desenvolvedor pode imaginar inúmeras maneiras diferentes de alterá-lo.

Às vezes, o código é desagradável pra caralho, e qualquer tentativa de limpá-lo deixa você em um estado pior. Escrever um código limpo sem entender as consequências de suas ações também pode ser um ritual de convocação para um código sustentável.

Isso não quer dizer que o código limpo seja ruim, mas às vezes a prática do código limpo é mais semelhante a varrer os problemas para debaixo do tapete. O** código depuravel não é necessariamente limpo**, e o código repleto de verificações ou tratamento de erros raramente torna a leitura agradável.

Regra 1: O computador está sempre pegando fogo.

O computador está pegando fogo e o programa travou na última vez em que foi executado.

A primeira coisa que um programa deve fazer é garantir que está começando de um estado conhecido, bom e seguro antes de tentar realizar qualquer trabalho. Às vezes, não há uma cópia limpa do estado porque o usuário a excluiu ou atualizou o computador. O programa travou na última vez que foi executado e, paradoxalmente, o programa também está sendo executado pela primeira vez.

Por exemplo, ao ler e gravar o estado do programa em um arquivo, vários problemas podem ocorrer:

O arquivo está faltando
O arquivo está corrompido
O arquivo é uma versão mais antiga ou mais recente
A última alteração no arquivo está inacabada
O sistema de arquivos estava mentindo para você

Estes não são problemas novos e os bancos de dados têm lidado com eles desde o início dos tempos (01/01/1970). Usar algo como o SQLite resolverá muitos desses problemas para você, mas se o programa travou na última vez em que foi executado, o código pode ser executado com os dados errados ou da maneira errada também.

Com programas programados, por exemplo, você pode garantir que os seguintes acidentes ocorrerão:

Ele é executado duas vezes na mesma hora por causa do horário de verão.
Ele é executado duas vezes porque um operador esqueceu que já havia sido executado.
Ele perderá uma hora, devido à falta de disco na máquina ou a problemas misteriosos de rede na nuvem.
Levará mais de uma hora para ser executado e pode atrasar chamadas subsequentes do programa.
Será executado com a hora errada do dia
Ele inevitavelmente será executado próximo a um limite, como meia-noite, final do mês, final do ano e falha devido a erro aritmético.

A criação de um software robusto começa com a criação de um software que assumiu que travou na última vez em que foi executado e trava sempre que não sabe a coisa certa a fazer. A melhor coisa sobre lançar uma exceção em vez de deixar um comentário como “Isso não deveria acontecer” é que, quando inevitavelmente acontecer, você terá uma vantagem inicial na depuração de seu código.

Você também não precisa se recuperar desses problemas - basta deixar o programa desistir e não piorar as coisas. Pequenas verificações que geram uma exceção podem economizar semanas de rastreamento por meio de logs, e um arquivo de bloqueio simples pode economizar horas de restauração do backup.

O código fácil de depurar é o código que verifica se as coisas estão corretas antes de fazer o que foi solicitado, o código que facilita voltar a um bom estado conhecido e tentar novamente e o código que possui camadas de defesa para forçar erros para emergir o mais cedo possível.

Regra 2: Seu programa está em guerra consigo mesmo.

_ Os maiores ataques DoS do Google vêm de nós mesmos - porque temos sistemas realmente grandes - embora de vez em quando alguém apareça e tente nos dar uma corrida pelo nosso dinheiro, mas na verdade somos mais capazes de nos martelar no chão do que qualquer um Mais é._
Isso vale para todos os sistemas.

Astrid Atkinson, livro Engenharia para o Jogo Longo

O software sempre travou na última vez em que foi executado e agora está sempre sem CPU, sem memória e sem disco também. Todas as threads estão martelando uma fila vazia, todos estão tentando novamente uma solicitação com falha que expirou há muito tempo e todos os servidores pausaram para coleta de lixo ao mesmo tempo. Não apenas o sistema está quebrado, mas está constantemente tentando quebrar a si mesmo.

Mesmo verificar se o sistema está realmente em execução pode ser bastante difícil.

Pode ser muito fácil implementar algo que verifique se o servidor está em execução, mas não se está lidando com solicitações. A menos que você verifique o tempo de atividade, é possível que o programa falhe entre cada verificação. As verificações de integridade também podem desencadear bugs: c*onsegui escrever verificações de integridade que travaram o sistema que deveria proteger. Em duas ocasiões distintas*, com três meses de diferença.

Em software, escrever código para lidar com erros inevitavelmente levará à descoberta de mais erros para lidar, muitos deles causados pelo próprio tratamento de erros. Da mesma forma, as otimizações de desempenho muitas vezes podem ser a causa de gargalos no sistema – criar um aplicativo agradável de usar em uma guia pode tornar um aplicativo difícil de usar quando você tem vinte cópias dele em execução.

Outro exemplo é quando um trabalhador(thread) em um pipeline está executando muito rápido e esgotando a memória disponível antes que a próxima parte tenha a chance de alcançá-lo. Se preferir uma metáfora de carro: engarrafamentos. Acelerar é o que os cria e pode ser visto na maneira como o congestionamento se move para trás no trânsito. As otimizações podem criar sistemas que falham sob carga alta ou pesada, geralmente de maneiras misteriosas.

Em outras palavras: quanto mais rápido você fizer isso, mais difícil será empurrado e, se você não permitir que seu sistema empurre para trás nem um pouco, não se surpreenda se ele quebrar.

A contrapressão é uma forma de feedback dentro de um sistema, e um programa fácil de depurar é aquele em que o usuário está envolvido no loop de feedback, tendo uma visão de todos os comportamentos de um sistema, o acidental, o intencional, o desejado, e os indesejados também. O código depuravel é fácil de inspecionar, onde você pode observar e entender as mudanças que estão acontecendo.

Regra 3: O que você não elimina a ambiguidade agora, você depura mais tarde.
Em outras palavras: não deve ser difícil olhar para as variáveis em seu programa e descobrir o que está acontecendo. Com ou sem algumas sub-rotinas de álgebra linear aterrorizantes, você deve se esforçar para representar o estado do seu programa da forma mais óbvia possível. Isso significa coisas como não mudar de ideia sobre o que uma variável faz no meio de um programa, se houver um pecado capital óbvio, é usar uma única variável para dois propósitos diferentes.

Também significa evitar cuidadosamente o problema do semipredicado, nunca usando um único valor ( count) para representar um par de valores ( boolean, count). Evitando coisas como retornar um número positivo para um resultado e retornar -1 quando nada corresponder. O motivo é que é fácil acabar na situação em que você deseja algo como "0, but true"(e notavelmente, o Perl 5 tem esse recurso exato) ou cria um código difícil de compor com outras partes do sistema ( -1 pode ser uma entrada válida para a próxima parte do programa, em vez de um erro).

Juntamente com o** uso de uma única variável para dois propósitos, pode ser tão ruim quanto usar um par de variáveis para um único propósito** — especialmente se forem booleanas. Não quero dizer que manter um par de números para armazenar um intervalo seja ruim, mas usar vários booleanos para indicar em que estado seu programa está geralmente é uma máquina de estado disfarçada.

Quando o estado não flui de cima para baixo, dê ou tire o loop ocasional, é melhor dar ao estado uma variável própria e limpar a lógica. Se você tiver um conjunto de booleanos dentro de um objeto, substitua-o por uma variável chamada estado e use um enum (ou uma string se persistir em algum lugar). As instruções if acabam parecendo if state == name e param de parecer if bad_name && !alternate_option.

Mesmo quando você torna a máquina de estado explícita, ainda pode errar: às vezes o código tem duas máquinas de estado escondidas dentro. Tive grande dificuldade em escrever um proxy HTTP até tornar cada máquina de estado explícita, rastreando o estado da conexão e analisando o estado separadamente. Quando você mescla duas máquinas de estado em uma, pode ser difícil adicionar novos estados ou saber exatamente em que estado algo deve estar.

Isso é muito mais sobre criar coisas que você não terá que depurar, do que tornar as coisas fáceis de depurar. Ao elaborar a lista de estados válidos, é muito mais fácil rejeitar os inválidos completamente, em vez de deixar acidentalmente um ou dois passarem.

Regra 4: Comportamento acidental é um comportamento esperado.

Quando você não tem certeza sobre o que uma estrutura de dados faz, os usuários preenchem as lacunas — qualquer comportamento do seu código, intencional ou acidental, acabará por ser considerado em outro lugar. Muitas linguagens de programação convencionais tinham tabelas de hash pelas quais você podia iterar, o que meio que preservava a ordem de inserção, na maioria das vezes.

Algumas linguagens optaram por fazer a tabela hash se comportar como muitos usuários esperavam, iterando pelas chaves na ordem em que foram adicionadas, mas outras optaram por fazer a tabela hash retornar as chaves em uma ordem diferente, a cada iteração. No último caso, alguns usuários reclamaram que o comportamento não era aleatório o suficiente.

Tragicamente, qualquer fonte de aleatoriedade em seu programa será eventualmente usada para fins de simulação estatística, ou pior, criptografia, e qualquer fonte de ordenação será usada para classificação.

Em um banco de dados, alguns identificadores carregam um pouco mais de informação do que outros. Ao criar uma tabela, um desenvolvedor pode escolher entre diferentes tipos de chave primária. A resposta correta é um UUID ou algo indistinguível de um UUID. O problema com as outras opções é que elas podem expor informações de pedido, bem como identidade, ou seja, não apenas se, a == b mas se a <= b, e outras opções significam chaves de incremento automático.

Com uma chave de incremento automático, o banco de dados atribui um número a cada linha da tabela, adicionando 1 quando uma nova linha é inserida. Isso cria uma espécie de ambiguidade: as pessoas não sabem qual parte dos dados é canônica. Em outras palavras: você classifica por chave ou por carimbo de data/hora? Como nas tabelas de hash anteriores, as pessoas decidirão a resposta certa por si mesmas. O outro problema é que os usuários também podem adivinhar facilmente os outros registros de chaves próximos.

Em última análise, qualquer tentativa de ser mais inteligente do que um UUID sairá pela culatra: já tentamos com códigos postais, números de telefone e endereços IP, e falhamos miseravelmente todas as vezes. Os UUIDs podem não tornar seu código mais depuravel, mas um comportamento menos acidental tende a significar menos acidentes.

A ordem não é a única informação que as pessoas extrairão de uma chave: se você criar chaves de banco de dados construídas a partir de outros campos, as pessoas jogarão fora os dados e os reconstruirão a partir da chave. Agora você tem dois problemas: quando o estado de um programa é mantido em mais de um lugar, é muito fácil que as cópias comecem a discordar umas das outras. É ainda mais difícil mantê-los sincronizados se você não tiver certeza de qual deles precisa alterar ou qual deles você alterou.

Tudo o que você permitir que seus usuários façam, eles implementarão. Escrever código depuravel é pensar antecipadamente sobre as maneiras pelas quais ele pode ser mal utilizado e como outras pessoas podem interagir com ele em geral.

Regra 5: A depuração é social, antes de ser técnica.

Quando um projeto de software é dividido em vários componentes e sistemas, pode ser consideravelmente mais difícil encontrar bugs. Depois de entender como o problema ocorre, talvez seja necessário coordenar as alterações em várias partes para corrigir o comportamento. Corrigir bugs em um projeto maior é menos sobre encontrar os bugs e mais sobre convencer as outras pessoas de que eles são reais, ou mesmo que uma correção é possível.

Os bugs persistem no software porque ninguém tem certeza absoluta de quem é o responsável pelas coisas. Em outras palavras, é mais difícil depurar o código quando nada está escrito, tudo deve ser perguntado no Slack e nada é respondido até que a única pessoa que sabe faça logon.

Planejamento, ferramentas, processo e documentação são as maneiras pelas quais podemos corrigir isso.

O planejamento é como podemos remover o estresse de estar de plantão, com estruturas para gerenciar incidentes. Os planos são como mantemos os clientes informados, trocamos pessoas quando estão de plantão por muito tempo e como rastreamos os problemas e introduzimos mudanças para reduzir riscos futuros. As ferramentas são a maneira pela qual desqualificamos o trabalho e o tornamos acessível a outras pessoas. O processo é a maneira pela qual podemos remover o controle do indivíduo e entregá-lo à equipe.

As pessoas vão mudar, as interações também, mas os processos e ferramentas serão mantidos à medida que a equipe mudar com o tempo. Não é tanto valorizar um mais do que o outro, mas construir um para apoiar mudanças no outro. O processo também pode ser usado para remover o controle da equipe, então nem sempre é bom ou ruim, mas sempre há algum processo de trabalho, mesmo quando não está escrito, e o ato de documentá-lo é o primeiro passo para permitir que outras pessoas o modifiquem.

A documentação significa mais do que arquivos de texto: a documentação é como você transfere responsabilidades, como atualiza as novas pessoas e como comunica o que mudou para as pessoas afetadas por essas mudanças. Escrever documentação requer mais empatia do que escrever código, e mais habilidade também: não há flags de compilador ou verificadores de tipo fáceis, e é fácil escrever muitas palavras sem documentar nada.

Sem documentação, como você pode esperar que as pessoas tomem decisões informadas ou até mesmo concordem com as consequências do uso do software? Sem documentação, ferramentas ou processos, você não pode dividir o ônus da manutenção ou mesmo substituir as pessoas atualmente sobrecarregadas com a tarefa.

Tornar as coisas fáceis de depurar se aplica tanto aos processos em torno do código quanto ao próprio código, deixando claro em quem você terá que se apoiar para consertar o código.

Código fácil de depurar é fácil de explicar.
Uma ocorrência comum durante a depuração é perceber o problema ao explicá-lo para outra pessoa. A outra pessoa nem precisa existir, mas você tem que se forçar a começar do zero, explicar a situação, o problema, os passos para reproduzi-lo, e muitas vezes esse enquadramento é suficiente para nos dar uma ideia da resposta.

Se apenas. Às vezes, quando pedimos ajuda, não pedimos a ajuda certa, e sou tão culpado disso quanto qualquer um - é uma aflição tão comum que tem nome: “O problema XY”: como faço para obter o últimas três letras de um nome de arquivo? Oh? Não, eu quis dizer a extensão do arquivo.

Falamos sobre problemas em termos das soluções que entendemos e falamos sobre as soluções em termos das consequências que conhecemos. Depurar é aprender da maneira mais difícil sobre consequências inesperadas e soluções alternativas, e envolve uma das coisas mais difíceis que um programador pode fazer: admitir que fez algo errado.

Afinal, não era um bug do compilador.

Fonte: programming is terrible lessons learned from a life wasted
https://programmingisterrible.com/post/173883533613/code-to-debug

Beacon API! Use para telemetria de seus projetos web

Uriel dos Santos Souza — Wed, 03 May 2023 13:04:22 +0000

Os aplicativos da Web geralmente precisam emitir solicitações que relatam eventos, atualizações de estado e análises para um ou mais servidores. Tais solicitações normalmente não requerem processamento de resposta no cliente (por exemplo, resultam em 204 ou 200 códigos de resposta HTTP com um corpo de resposta vazio) e não devem competir por rede e recursos de computação com outras operações de alta prioridade, como buscar recursos críticos, reagir para inserir, executar animações e assim por diante. No entanto, essas solicitações unidirecionais (beacons) também são responsáveis por fornecer dados críticos de aplicativos e medições, forçando os desenvolvedores a usar métodos caros para garantir sua entrega:

Os desenvolvedores optam pela entrega imediata de cada beacon, em vez de combinar e adiar a entrega, pois isso proporciona melhores taxas de entrega. Adiar a entrega pode significar que a solicitação de beacon pode não ter tempo suficiente para ser concluída com sucesso, o que leva à perda de dados importantes do aplicativo.
Os desenvolvedores optam por emitir solicitações de bloqueio por meio de XMLHttpRequest síncronos, inserindo loops ocupados no-op ou usando outras técnicas que impedem o agente do usuário de executar operações de tempo crítico (por exemplo, clicar, descarregar e outros manipuladores) e prejudicar a experiência do usuário. O comportamento de bloqueio é usado para fornecer uma taxa de entrega aprimorada, pois evita que o agente do usuário e o sistema operacional cancelem a solicitação se a página for descarregada, suspensa ou eliminada pelo sistema.

A incompatibilidade entre os requisitos de entrega e processamento acima deixa a maioria dos desenvolvedores com uma escolha difícil e adoção generalizada de técnicas de bloqueio que prejudicam a experiência do usuário. Esta especificação define uma interface que os desenvolvedores da Web podem usar para agendar a entrega assíncrona e sem bloqueio de dados que minimiza a contenção de recursos com outras operações de tempo crítico, garantindo que tais solicitações ainda sejam processadas e entregues ao destino:

As solicitações de beacon são priorizadas para evitar a competição com operações de tempo crítico e solicitações de rede de prioridade mais alta.
As solicitações de beacon podem ser agrupadas de forma eficiente pelo agente do usuário para otimizar o uso de energia em dispositivos móveis.
As solicitações de beacon são garantidas para serem iniciadas antes que a página seja descarregada e podem ser executadas até a conclusão sem exigir solicitações de bloqueio ou outras técnicas que bloqueiam o processamento de eventos interativos do usuário.

Enviar um beacon é simples(já esta em todos os navegadores modernos!)

As solicitações de beacon não exigem uma resposta. Esta é uma grande diferença das solicitações regulares XHR ou fetch em que o cliente (navegador) espera uma resposta do servidor.
As solicitações de beacon são iniciadas antes que uma página seja descarregada, mesmo quando você fecha o navegador.
As solicitações de beacon são concluídas sem exigir uma solicitação de bloqueio (XHR, por exemplo).
As solicitações de beacon usam o método HTTP POST.

navigator.sendBeacon('/url-que-vai-receber-o-dado', data);

Uma implementação maior!


//evento não bloqueante! Não bloqueia o loop de eventos do JS no cliente!
function reportEvent(event) {
    var data = JSON.stringify({
      event: event,
      time: performance.now()
    });
    navigator.sendBeacon('/collector', data);
  }

  // emite beacon sem bloqueio com análise de sessão da página
   // transições para o estado de segundo plano (Page Visibility API)

  document.addEventListener('visibilitychange', function() {
    if (document.visibilityState === 'hidden') {
      var sessionData = buildSessionReport();
      navigator.sendBeacon('/url', sessionData);
    }
  });

As solicitações iniciadas por meio do sendBeacon()método não bloqueiam ou competem com o trabalho de tempo crítico, podem ser priorizadas pelo agente do usuário para melhorar a eficiência da rede e eliminar a necessidade de usar operações de bloqueio para garantir a entrega de dados beacon.

OBS:
O método sendBeacon() não fornece capacidade de personalizar o método de solicitação, fornecer cabeçalhos de solicitação personalizados ou alterar outras propriedades de processamento da solicitação e resposta. Os aplicativos que exigem configurações não padrão para tais solicitações devem usar a API [ FETCH ] com keepalive definido como true.

Beacons são úteis para enviar dados ao servidor quando uma página é descarregada(load completo) (por exemplo, fechamento do navegador, navegações de página, etc.).

 if (navigator.sendBeacon) {
  // faça a magica acontecer 
  navigator.sendBeacon('/collector', Data);

} else {
  // esse navegador não tem beacon 
  // use XHR ou fetch
}

Formatos aceitos pelo beacon para envio

ArrayBufferView
Blob
DOMStringou
FormData O data é opcional!

Casos de uso

Saber quanto tempo um usuário ficou numa sessão!
Quais são os controles de interface do usuário usados pelos usuários!
Qualquer outro tipo de informação de telemetria a ser capturada!

Há um limite nos dados que podem ser enviados ao servidor usando a API Beacon. No entanto, esse limite não é uniforme em todos os navegadores e agentes de usuário.

Você já usa a API?

Fontes:
https://www.w3.org/TR/beacon/

https://javascript.plainenglish.io/save-your-analytics-data-with-the-beacon-and-pagevisibility-apis-f7d6a01087c4

Uma forma de ensinar OOP para programadores procedurais na década de 80 com cartões!

Uriel dos Santos Souza — Mon, 10 Apr 2023 16:12:56 +0000

Este e um texto traduzido livremente!

Kent Beck, Apple Computer, Inc.
Ward Cunningham, Wyatt Software Services, Inc.

Dos Anais da Conferência OOPSLA'89,
de 1 a 6 de outubro de 1989, Nova Orleans, Louisiana
E da edição especial do SIGPLAN Notices
Volume 24, Número 10, outubro de 1989

Introdução

É difícil introduzir programadores procedimentais novatos e experientes à perspectiva antropomórfica necessária para o projeto orientado a objetos. Apresentamos os cartões CRC, que caracterizam os objetos pelo nome da classe, responsabilidades e colaboradores, como forma de dar aos alunos uma experiência direta dos objetos. Descobrimos que essa abordagem é bem-sucedida ao ensinar aos programadores novatos os conceitos de objetos e ao apresentar aos programadores experientes projetos complicados existentes.

1. Problema

O problema mais difícil no ensino de programação orientada a objetos é fazer com que o aluno desista do conhecimento global de controle que é possível com programas procedurais e confie no conhecimento local de objetos para realizar suas tarefas. Projetos novatos estão repletos de regressões ao pensamento global: variáveis globais gratuitas, ponteiros desnecessários e confiança inadequada na implementação de outros objetos.
Como aprender sobre objetos requer uma mudança na abordagem geral, ensinar objetos reduz-se a ensinar o design de objetos. Nós nos concentramos em design, quer estejamos ensinando conceitos básicos para novatos ou as sutilezas de um design complicado para programadores de objetos experientes.

Em vez de tentar tornar o design de objetos o mais parecido possível com o design processual, descobrimos que a maneira mais eficaz de ensinar a maneira idiomática de pensar com objetos é imergir o aluno na "objetividade" do material. Para fazer isso, devemos remover o máximo possível de material familiar, esperando que detalhes como sintaxe e operação do ambiente de programação sejam captados com rapidez suficiente, uma vez que os fundamentos tenham sido totalmente compreendidos.

É nesse contexto que descreveremos nossa perspectiva sobre o design de objetos, sua manifestação concreta, os cartões CRC (para Classe, Responsabilidade e Colaboração) e nossa experiência no uso desses cartões para ensinar os fundamentos e as sutilezas do pensamento com objetos.

2. Perspectiva

Projetos procedimentais podem ser caracterizados em um nível abstrato como tendo processos, fluxos de dados e armazenamentos de dados [1], independentemente da linguagem de implementação ou do ambiente operacional. Queríamos criar um conjunto semelhante de princípios fundamentais para projetos de objetos. Estabelecemos três dimensões que identificam o papel de um objeto em um design: nome da classe, responsabilidades e colaboradores.
O nome de classe de um objeto cria um vocabulário para discutir um projeto. De fato, muitas pessoas observaram que o projeto de objeto tem mais em comum com o projeto de linguagem do que com o projeto de programa processual. Incentivamos os alunos (e passamos um tempo considerável enquanto projetamos) a encontrar o conjunto certo de palavras para descrever nossos objetos, um conjunto que seja internamente consistente e evocativo no contexto do ambiente de design mais amplo.

As responsabilidades identificam os problemas a serem resolvidos. As soluções existirão em muitas versões e refinamentos. Uma responsabilidade serve como um identificador para discutir possíveis soluções. As responsabilidades de um objeto são expressas por um punhado de frases verbais curtas, cada uma contendo um verbo ativo. Quanto mais puder ser expresso por essas frases, mais poderoso e conciso será o design. Mais uma vez, procurar as palavras certas é um uso valioso do tempo durante o design.

Uma das características distintivas do design de objetos é que nenhum objeto é uma ilha. Todos os objetos estão em relação com outros, de quem dependem para serviços e controle. A última dimensão que usamos na caracterização de projetos de objetos são os colaboradores de um objeto. Nomeamos objetos colaboradores que enviarão ou receberão mensagens no decorrer do cumprimento de responsabilidades. A colaboração não é necessariamente uma relação simétrica. Por exemplo, em Smalltalk-80 [2] , View e Controller operam quase iguais (veja o exemplo abaixo), enquanto OrderedCollection oferece um serviço com pouca consideração ou mesmo consciência de seu cliente.

Ao longo deste artigo, deliberadamente obscurecemos a distinção entre classes e instâncias. Essa informalidade não é tão confusa quanto pode parecer porque a concretude de nosso método substitui a nomeação de instâncias. Isso também torna nosso método de ensino independente de uma linguagem baseada em classe ou protótipo ser usada.

3. Cartões CRC
O segundo autor inventou os cartões CRC em resposta à necessidade de documentar as decisões de design colaborativo. Os cartões começaram como uma pilha HyperCard [3] que fornecia indexação automática aos colaboradores, mas foram movidos para sua forma atual para resolver problemas de portabilidade e independência do sistema.
Como nosso trabalho anterior na documentação da colaboração de objetos [4] , os cartões CRC representam explicitamente vários objetos simultaneamente. No entanto, em vez de simplesmente traçar os detalhes de uma colaboração na forma de envio de mensagens, os cartões CRC colocam o foco do designer na motivação para a colaboração, representando (potencialmente) muitas mensagens como uma frase de texto em inglês.

Figura 1. Um cartão de índice de Colaborador de Responsabilidade de Classe (CRC)

Como os usamos atualmente, todas as informações de um objeto são escritas em um cartão de índice de 4" x 6". Estes têm as vantagens de serem baratos, portáteis, prontamente disponíveis e familiares. A Figura 1 mostra um cartão idealizado. O nome da classe aparece sublinhado no canto superior esquerdo, uma lista de responsabilidades aparece abaixo dela nos dois terços esquerdos do cartão e a lista de colaboradores aparece no terço direito.

Figura 2. Cartões CRC descrevendo as responsabilidades e colaborações do Model, View e Controller de Smalltalk.

A Figura 2 mostra um exemplo obtido da imagem Smalltalk-80, a muito incompreendida estrutura de interface do usuário Model, View e Controller. Mostramos deliberadamente apenas uma parte das responsabilidades que cada um desses objetos assume para clareza de exposição. Observe que os cartões são colocados de modo que View e Controller se sobreponham (o que implica em estreita colaboração) e colocados acima do Model (o que implica supervisão). Descobrimos que esses e outros agrupamentos informais ajudam na compreensão de um projeto. As partes, por exemplo, muitas vezes são dispostas abaixo do todo. Da mesma forma, os refinamentos de uma abstração podem ser coletados e tratados como uma única pilha de cartas com a carta mais abstrata no topo, onde ela pode representar o resto.

O design com os cartões tende a progredir de conhecidos para desconhecidos, em vez de de cima para baixo ou de baixo para cima. Observamos duas equipes chegando essencialmente ao mesmo projeto por meio de sequências quase opostas, uma começando com drivers de dispositivo e a outra com modelos de alto nível. O problema exigia um certo conjunto de capacidades que ambas as equipes descobriram ao cumprir os requisitos do projeto.

Sugerimos direcionar um projeto para a conclusão com o auxílio de cenários de execução. Começamos com apenas uma ou duas cartas óbvias e começamos a jogar "e se". Se a situação exigir uma responsabilidade ainda não coberta por um dos objetos, adicionamos a responsabilidade a um dos objetos ou criamos um novo objeto para tratar dessa responsabilidade. Se um dos objetos ficar muito confuso durante esse processo, copiamos as informações de seu cartão para um novo cartão, buscando maneiras mais concisas e poderosas de dizer o que o objeto faz. Se não for possível reduzir ainda mais as informações, mas o objeto ainda for muito complexo, criamos um novo objeto para assumir algumas das responsabilidades.

Encorajamos os alunos a pegar o cartão cujo papel estão assumindo enquanto "executam" um cenário. Não é incomum ver um designer com um cartão em cada mão, agitando-o, fazendo uma forte identificação com os objetos ao descrever sua colaboração.

Ressaltamos a importância de criar objetos não para atender às míticas necessidades futuras, mas apenas sob as demandas do momento. Isso garante que um projeto contenha apenas o máximo de informações que o designer experimentou diretamente e evita a complexidade prematura. Trabalhar em equipe ajuda aqui porque um designer preocupado pode influenciar os membros da equipe sugerindo cenários voltados especificamente para suspeitas de fraquezas ou omissões.

A capacidade de organizar rapidamente e endereçar fichas espacialmente é mais valiosa quando um projeto está incompleto ou mal compreendido. Vimos designers referirem-se repetidamente a um cartão que pretendiam escrever, apontando para onde o colocariam quando concluído.

4. Experiência

Um dos contextos em que utilizamos os cartões CRC é uma aula de três horas intitulada "Pensando com Objetos", destinada a profissionais de computação que já programaram, mas cujas funções não necessariamente envolvem programação diária. A aula prossegue apresentando um exemplo de fluxo de dados (uma escola, com processos de ensino e administração) que é então reformulado em termos de objetos com responsabilidades e colaboradores (como Professor, Zelador e Diretor). A turma então forma duplas e passa uma hora projetando os objetos em um caixa eletrônico, exercício escolhido pela familiaridade de todos com o aplicativo e sua pronta decomposição em objetos para controlar os aparelhos, comunicar-se com o banco de dados do banco central e controlar o usuário. interface. (Consulte o apêndice para obter uma solução de exemplo.
Ao ensinar este curso a mais de uma centena de alunos, não encontramos ninguém que fosse incapaz de completar o exercício sem ajuda, embora um par em cada classe geralmente precise de algumas dicas para começar. Embora não tenhamos feito estudos de acompanhamento, a classe é considerada um recurso valioso na empresa e ainda é bem atendida com uma longa lista de espera quase um ano após seu início.

Também pedimos aos programadores de objetos qualificados que tentassem usar cartões CRC. Nossa experiência pessoal sugere um papel para os cartões na engenharia de software, embora ainda não possamos reivindicar uma metodologia completa (outros [5][6] desenvolveram metodologias mais completas que podem tirar proveito dos métodos CRC). Sabemos de um caso em que os cartões acabados foram entregues a um cliente como documentação de design (parcial). Embora a equipe que produziu os cartões tenha ficado bastante satisfeita com o design, o destinatário não conseguiu entender os cartões fora do contexto.

Outra experiência ilustra a importância do contexto estabelecido pelo manuseio e discussão das cartas. Tínhamos filmado designers experientes resolvendo um problema semelhante ao do caixa eletrônico. Nossa colocação de câmera tornou os cartões e as mãos dos designers visíveis, mas não a escrita nos cartões. Os espectadores da fita não tiveram problemas para acompanhar o desenvolvimento e muitas vezes pediram que a fita fosse interrompida para que pudessem expressar suas opiniões. Os momentos mais marcantes ocorreram quando a explicação do espectador exigia que ele apontasse para um cartão borrado na imagem congelada na tela.

Finalmente, usamos cartões CRC para explicar projetos complexos. Alguns minutos de introdução são suficientes para preparar o público para uma apresentação baseada em cartão. Os cartões podem ser feitos com antecedência ou escritos na hora. Este último permite que a complexidade de um projeto seja revelada lentamente, um processo relacionado ao "gerenciamento de mentiras" de Dave Thomas. Os cartões estão sendo usados como acessórios para ajudar a contar uma história de computação. Os cartões permitem que seja contado sem recorrer à sintaxe ou idioma da linguagem de programação.

5. Conclusão

Tomando nossa perspectiva como base, damos a novatos e programadores experientes uma experiência de aprendizado que lhes ensina algo valioso sobre objetos. Os cartões CRC dão ao aluno que nunca encontrou objetos uma compreensão física da objetividade e os prepara para entender o vocabulário e os detalhes de idiomas específicos. Os cartões CRC também fornecem uma experiência útil e convincente com objetos para aqueles que aprenderam os mecanismos dos objetos, mas ainda não perceberam seu valor.
Ragu Raghavan [7] disse que na mudança para objetos os programadores fortes se tornam mais fortes, mas os programadores mais fracos são deixados para trás. Usando os cartões em configurações de grupo, descobrimos que mesmo os programadores mais fracos, sem uma compreensão profunda dos objetos, poderiam contribuir para projetos de objetos. Especulamos que, como os projetos são muito mais concretos e a relação lógica entre os objetos é mais fácil de entender, avaliar e modificar um projeto.

Ficamos surpresos com o valor de mover fisicamente as cartas. Quando os alunos pegam um objeto, eles parecem se identificar mais prontamente com ele e estão preparados para lidar com o restante do design de sua perspectiva. É o valor dessa interação física que nos levou a resistir à informatização dos cartões.

É exatamente esse problema – integrar os cartões com metodologias de design mais amplas e com ambientes de linguagem específicos – que acreditamos ser o mais promissor para o futuro. A necessidade de reter o valor da interação física aponta para a necessidade de um novo tipo de interface de usuário e ambiente de programação muito além do que temos hoje, pois nossos sistemas atuais estão além dos ambientes orientados a ferramentas do passado.

Referências
[1] DeMarco, T.: Análise Estruturada e Especificação de Sistema, Yourdon, 1978.
[2] Imagem Smalltalk-80, Xerox Corp, 1983.

[3] Manual do HyperCard, Apple Computer Inc.

[4] Cunningham, W. e Beck, K.: "A Diagram for Object-Oriented Programs", em Proceedings of OOPSLA-86, outubro de 1986.

[5] Wirfs-Brock, R. e Wilkerson, B. "Design orientado a objetos: uma abordagem voltada para a responsabilidade", submetido à OOPSLA '89.

[6] Reenskaug, T.: "A Methodology for the Design and Description of Complex, Object-Oriented Systems", relatório técnico, Centro de Pesquisa Industrial, Oslo, Noruega, novembro de 1988.

[7] Raghavan, R.: "Panel: Experiences with Reusability", in Proceedings of OOPSLA '88, outubro de 1988.

Fonte: https://c2.com/doc/oopsla89/paper.html

O que faz de uma linguagem Orientada a Objetos? Por Peter Wegner

Uriel dos Santos Souza — Thu, 16 Mar 2023 00:27:24 +0000

Isso era um assunto controverso nos anos 80.

Em 87, Peter Wegner, publicou um artigo na OOPSLA que resolveu a questão (pelo menos entre aqueles que concordam com o Wegner)
Para uma linguagem ser Orientada a Objetos ela precisa segundo Wegner

ser baseada em objetos, ou seja, deve ser fácil programar objetos que encapsulam dados e operações;

ser baseadas em classes, ou seja, cada objeto pertence a (ou é fabricado a partir de) uma classe; e +
permitir herança, ou seja, deve ser fácil agrupar classes em hierarquias de subclasses e superclasses.

Outros estudiosos (chatos?) acrescentam outros itens à lista: (eu não concordo - Wegner)
enlace dinâmico, tardio (late binding)

A linguagem Self é uma grande exceção entre as linguagens claramente orientada a objetos: ela não possui classes.

JS e Lua tem coletores de lixo e não são baseadas em classes.

Para Wegner essas não são linguagem OOP.

Fontes:
https://dl.acm.org/doi/abs/10.1145/38765.38823

CDD - Cognitive Driven Development - Uma forma de programar criada por brasileiros!

Uriel dos Santos Souza — Mon, 13 Mar 2023 14:08:09 +0000

A importância de desenvolver estratégias que reduzam o cognitive load dos nossos códigos para garantir seu entendimento por todos. Foi desse raciocínio que nasceu o conceito de Cognitive-Driven Development, ou design orientado ao entendimento.

CDD - Cognitive Driven Development

Descobrir quais são as nossas limitações de entendimento e como a nossa mente atua nessa questão é tema de estudo de longa data. O artigo mais influente nessa área vem de 1956 e foi escrito pelo psicólogo George A. Miller, da universidade de Harvard. O título da famosa publicação é “The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information“.
http://psychclassics.yorku.ca/Miller/

Miller explica que provavelmente nós temos uma severa limitação na hora de processar informações. No resumo do resumo, é explicado que temos um limite de itens a serem entendidos em determinado momento que varia entre 5 e 9. Por isso o título +-7. Essa ideia foi fortemente explorada e é bem aceito hoje em dia que realmente temos essa limitação.

Esforço cognitivo, ou carga cognitiva se refere ao nível de utilização de recursos psicológicos como memórias, atenção, percepção, representação de conhecimento, raciocínio e criatividade na resolução de problemas.

A Teoria da Carga Cognitiva fundamenta-se na impossibilidade que o ser humano manifesta em processar muitas informações em simultâneo. O excesso de informação gera um esforço demasiado para todo o processo cognitivo o que origina uma sobrecarga cognitiva que dificulta a compreensão do conteúdo que se deseja apreendido.
https://sites.google.com/site/teoriadacargacognitiva/a-contribuicao-dos-principios-da-teoria-da-carga-cognitiva-na-aprendizagem-multimedia/resumo-1

Para entender mais sobre a teoria da carga cognitiva
http://www.ucs.mun.ca/~bmann/0_ARTICLES/CogLoad_Paas04.pdf

Um trecho retirado do artigo referenciado diz o seguinte: “The load is called ‘intrinsic’ if it is imposed by the number of information elements and their interactivity.”

Em tradução livre, temos: “A carga é chamada de ‘intrínseca’ se for imposta pelo número de elementos de informação e sua interativida”.

E é da ideia de carga intrínseca que nasce a proposta de design de código orientado a entendimento. Caso a gente considere que um pedaço de código é um material que precisa ser entendido, como podemos diminuir de maneira eficaz a carga intrínseca dele?

Afinal, o que é Cognitive-Driven Development (CDD)?

Cognitive-Driven Development (CDD), ou em português desenvolvimento orientado a cognição, é uma estratégia para reduzir a sobrecarga cognitiva durante o desenvolvimento ao melhorar o design do código.

Ou seja, a ideia é manter os níveis de entendimento sobre um pedaço de código dentro
do que o ser humano pode entender bem! Ou seja, dentro de +-7 items simultaneos.

Limitando a carga intrínseca do código ou Ponto de Complexidade Intrínseca (ICP)

Uma das bases do Cognitive-Driven Development (CDD) é analisar e buscar limitar a complexidade de um código, esta limitação pode ser arbritrária decidida no time. Para que a gente consiga, de fato, ter uma maneira interessante de limitar a carga intrínseca do código que escrevemos, precisamos seguir alguns passos.

A primeira tarefa do time é decidir qual vai ser a unidade de código que será analisada. Por exemplo, se falarmos de uma linguagem orientada a objetos temos algumas possibilidades de definição de unidade de código, como, por:

método dentro de uma classe;
classe;
arquivo.

A equipe pode definir um número de linhas maximo por classe dentro de um arquivo.
100, ou seja o limite não pode passar de 100. Se passar outro arquivo deve ser criado.

O que mais foi explorado até agora(dentro dos teste internos an ZUP) é usar o arquivo como uma unidade de código a ter sua carga intrínseca limitada. Isso implica que se tivermos duas classes dentro do mesmo arquivo, vamos somar as cargas intrínsecas de cada uma e essa vai ser a carga total do arquivo.

Uma vez que a unidade de código a ser analisada foi definida, é importante que a equipe do projeto entre em um acordo sobre o que vai influenciar na carga. É o que chamamos de Intrisc Complex Point (ou Ponto de Complexidade Intrínseca) no Cognitive-Driven Development. Para facilitar, vamos referenciar estes pontos como ICP.

Aqui não existe regra, o objetivo do Cognitive-Driven Development (CDD) não é achar uma composição de Ponto de Complexidade Intrínseca (ICP) que forme uma métrica perfeita. A ideia é que a equipe, considerando suas características, encontre os ICP que façam sentido para aquele contexto.

Aquilo que a equipe achar naquele momento! E que pode mudar com o tempo!

E qual o limite de ICP que podemos ter então por unidade de código? Atualmente a nossa sugestão é que você tenha um número que seja o dobro ou maior ao número de ICP escolhidos. No exemplo citado temos cinco itens, então o limite por unidade de código seria dez ou mais.

Visão prática sobre o Ponto de Complexidade Intrínseca (ICP)

Por exemplo, a equipe de engenharia da Zup Edu definiu que para os projetos em Java que escrevemos, vamos considerar os itens abaixo como ICP:

branches de código padrões (if, else, loops, when, case do when, try, catch);
funções como argumento;
condicionais;
acoplamento com classes específicas do projeto;
herança de classe abstrata ou concreta (extends).

Cada equipe pode definir seu conjunto de ICP e revisitá-lo com frequência. Até porque a combinação de níveis de habilidade da equipe pode influenciar no escopo do projeto e em vários outros fatores que afetam a qualidade e complexidade do código. Outro detalhe muito interessante é que o conjunto de itens influencia diretamente no estilo de código.

Algumas dicas práticas para escolher e trabalhar melhor com ICPs:

Herança foi escolhida como ICP? O recado é: Use com moderação.
Condicional foi escolhida como ICP? O recado é: Não crie if com várias condicionais
Função como argumento foi escolhida como ICP? O recado é: Não exagerar em transformação de coleção.
Apenas acoplamento com classe específica foi escolhido como ICP? O recado é: Saiba das tecnologias que sustentam o projeto, vamos usar sem moderação.

A definição do limite de ICP por unidade de código ainda precisa de muita exploração. O importante para o Cognitive-Driven Development (CDD) é que exista um conjunto de itens claros que a equipe considere que dificulta o entendimento, assim como um limite estabelecido.

Benefícios de criar um entendimento sobre complexidade

Com um conjunto de ICP claro e um limite definido, muitas atividades e debates são facilitados no intervalo de tempo em que o combinado estiver valendo:

Esse código está complexo? Se o número de ICP estiver abaixo ou igual ao limite, a resposta é não.
Esse código vai passar no review? Se o número de ICP estiver abaixo ou igual ao limite, a resposta é sim.

Não importa se a pessoa é junior, plena, sênior ou qualquer outro nível. Ninguém vai escrever um código que passa do limite de complexidade definido pela equipe!

Um limite sempre arbitrário e simples para qualquer um entender!

Quaisquer outras discussões sobre complexidade agora têm uma regra clara. Entendemos que isso facilita bastante o dia a dia de comunicação dentro do projeto no que diz respeito à análise do código em si.

Como o Cognitive-Driven Development se relaciona com o que você já utiliza hoje em dia?

Importante notar que o Cognitive-Driven Development (CDD) não vem com a ideia de ser a principal referência dentro do design do seu código. Limitar a dificuldade de entendimento é algo que pode ser útil em qualquer ponto do projeto.

Imagine que você está escrevendo um caso de uso inspirado na arquitetura proposta pelo Clean Architecture. Se a equipe tiver definido os pontos de complexidade intrínseca (ICP) e o limite, você vai conseguir ter um caminho claro de como separar o código de modo a fazer o caso de uso e ainda manter o nível de carga cognitiva necessário para entendimento adequado com os padrões da equipe.

Olhando ainda para as ideias de camadas propostas pela Clean Architecture, você pode encontrar situações semelhantes na camada de entidades. As classes que estão no núcleo da sua aplicação tendem a ser transversais ao sistema todo. Elas podem ganhar mais atributos, métodos etc.

Então como fazer para saber o limite daquele código no que diz respeito a facilidade de entendimento? Mais uma vez a ideia do Cognitive-Driven Development (CDD) pode ser aplicada para facilitar.

A mesma linha de raciocínio pode ser aplicada quando você está se inspirando no Domain Driven Design, pensando no princípio da responsabilidade única etc.

Peguei este artigo da zup e fiz comentários que estão citados!
https://www.zup.com.br/blog/cognitive-driven-development-cdd

Uma definição em vídeo do autor Alberto Luiz Oliveira Tavares de Souza
https://www.youtube.com/watch?v=rqw_Jnv6ZX4

Fontes:
https://www.zup.com.br/blog/cognitive-driven-development-cdd
https://ieeexplore.ieee.org/document/9240662

Autores: Alberto Luiz Oliveira Tavares de Souza
Zup Innovation - Academy, São Paulo, SP, Brazil
E
Victor Hugo Santiago Costa Pinto
Zup Innovation - Academy,São Paulo,SP,Brazil

Entre em contato com um dos autores
https://twitter.com/alberto_souza

Ele é muito simpatico e sempre que pode responde a todos!

Lista de servidores VPS baratos

Uriel dos Santos Souza — Thu, 02 Mar 2023 12:24:37 +0000

Olá, quase todo mundo ama um cloud, uma AWS ou algo com netifly etc.
Como eu não sou todo mundo, eu prefiro servidor VPS ou parecido!

Alguns projetos pequenos cabem super bem neles! Um cloud ou algo com front separado é muito trabalho pra pouco retorno de projetos pessoais! Se for profissional é outro modo de pensar!
Versões frees de alguns serviços como aws/gcp e outros é muita do de cabeça pra gente fazer pouco(minha opinião)

Lista sem ordenamento!

https://www.time4vps.com/ - ele é barato e bem antigo. Quase não vejo reclamações!
Mas os servidores ficam Lituania. Se PING for importante pra você pode não ser uma boa ideia!
- https://contabo.com/ - relativamente barato. Uso ele tem uns 8 anos e nunca tive qualquer problema. Infelizmente eles aumentaram seus preços. Mas vale a pena. Você pode escolher entre EUA e Alemanha seu VPS. q Quando eu entrei tinha apenas Alemanha! OBS: Eles tem um serviço igual ao S3 da AWS mas muito mais barato!
- https://vpsdime.com/ - é um serviço que conheço pouco. Não sei muito dele. Mas seus VPS são bem baratos!
- https://www.digitalocean.com/ este nem precisa de palavras. Super conhecido!
- https://www.server4you.de/ super barato. Mas pouco conhecido. Seus servidores ficam na Alemanha

EDITADO - sugestões

///

Com pagamento em real
Já usei, não tive problemas

https://minivps.com.br/

Não usei mas pretendo

Você tem alguma indicação?
Eu sei que existem outros. Mas só quis começar a lista.
Eu mesmo gosto de ficar pesquisando por novidades!

Por favor deixe sua lista nos comentários!

Você quer alternativas a Heroku?

+ de 15 alternativas ao Heroku - nem todas grátis!

Uriel dos Santos Souza ・ Sep 8 '22

#heroku #braziliandevs

Fazendo um jabá!
Caso você esteja procurando um serviço simples de upload e download de arquivos sem registros ou logins!
Recomendo o https://shareallfiles.net/

shareallfiles.net

O que é processo e um thread?

Uriel dos Santos Souza — Tue, 17 Jan 2023 16:25:10 +0000

Hoje vamos falar um pouco de CPU.
Mais especificamente de processos e threads!
Falaremos aqui de forma simples sem entrar em muitos detalhes, para um entedimento básico do assunto.

O que é um processo?

Um processo em palavras simples é alguma coisa usar uma CPU(um processador).
Ou seja de forma simplificada, se um computador tem um só núcleo, ele só pode executar 1 processo por vez! Um único programa apenas! Hoje todos os novos chips tem N núcleos. Ou seja qualquer novo computador ou celular tem muitos processadores.

Quando você abre um programa, ele usa um processo. Ele ocupa totalmente esse CPU(no caso de um único núcleo)!
Antigamente quando só existia um unico núcleo ele ficaria tomado 100% do tempo por um unico programa!

Mas, resolveram isso de forma simples.
o kernel, por meio de uma interrupção de timer ou outro mecanismo semelhante, suspende um, salvando seu estado de máquina e substituindo-o pelo estado salvo anteriormente de outro.

O programa(processo) usa o núcleo por poucos milesimos, ai salva tudo na memoria. E outro processo passa a usar aquele núcleo por mais alguns milésimos tudo é salvo. Ai se pega o que foi salvo antes e processa por alguns milésimos, salva e assim por diante. É tão rapido que tudo parece paralelo.

Isso tudo em termos simples!
Hoje funciona de modo parecido!

Seu computador e celular tem bem mais de um núcleo.

Se você abrir poucos programas pode ser que nem se use todos os núcleos. Assim economizando energia eletrica.
Não tem motivos para usar todos os processadores é mais barato usar poucos.
Hoje um processo pode estar em mais de um núcleo ao mesmo tempo.
O navegador Chrome por exemplo, usa multiplos processos! Cada aba que você abre é um novo processo sendo criado pelo Chrome!

Hoje mesmo com multinúcleos a maioria dos programas usa um só!

Um processo pode criar outros processos, o qual chamamos de processos filhos!

O processo pode ter os seguintes estados: novo, pronto, em execução, aguardando, encerrado, suspenso.

As operações de processo podem ser facilmente controladas com a ajuda do PCB (bloco de controle de processo). Você pode considerá-lo como o cérebro do processo, que contém todas as informações cruciais relacionadas ao processamento, como id do processo, prioridade, estado e registro de conteúdo da CPU, etc.

Um processo é único. Não conversa facilmente com outro. Não compartilham memoria.
Para você conversar com outro processo precisa usar mensagens de IPC(Inter-Process Communication)
Onde cada mensagem enviada é copiada para o outro processo.

Processo 1 - "Oi processo 2"

A mensagem "Oi processo 2" acaba de ser copiada

Processo 2, recebe a mensagem
Processo 2 - "Oi, recebi usa mensagem"

A mensagem "Oi, recebi usa mensagem" acaba de ser copiada

Processo 1, recebe a mensagem.

A criação de cada processo requer chamadas de sistema separadas para cada processo.
É uma entidade de execução isolada e não compartilha dados e informações.
Os processos usam o mecanismo IPC (Inter-Process Communication) para comunicação que aumenta significativamente o número de chamadas do sistema.
O gerenciamento de processos leva mais chamadas de sistema.
Um processo tem sua própria pilha, memória heap com memória e mapa de dados.
Um processo demora para ser criado, demora mais pra terminar!

Agora sabemos o que é um processo por cima, sem muitos detalhes e existe muito mais coisas, Tem muito mais material detalhado na web, com todos os conceitos bem explicados. Passo a passo deixarei fontes no fim do artigo!

O que é thread?

Vamos falar de forma alta. Sem detalhes!

Sabemos o que é um processo. Mas dentro dele podem ter threads(um mini processo por núcleo). Um processo pode ter várias threads. Todos os threads de um processo compartilhamo mesmo espaço na memória e recursos do sistema.
Se um thread abrir um arquivo, outro pode ler ou mexer nele!
Isso não acontece entre processos!

Vamos imaginar que dentro de um processo existem vários pequenos trabalhadores.
Mais ou menos como uma fabrica.
Um processo com muitos funcionarios.

O bom de thread é que elas compartilham coisas!
Como estão dentro de um mesmo processo, tudo que o processo tem acesso, thread também tem!
Ou seja, threads podem conversar entre si e podem acessar os mesmos pontos da memória!
Isso torna as coisas mais rápidas!
Mas não mais simples de gerenciar!

Threads podem ter 3 estados: em execução, pronto e bloqueado.

Thread também é conhecido como processo leve. A ideia é alcançar o paralelismo dividindo um processo em vários threads. Por exemplo, em um navegador, várias guias podem ser threads diferentes. O MS Word usa vários threads: um thread para formatar o texto, outro thread para processar entradas.
Programas que suportam multithreading podem ser complicados de gerenciar!

Usando processos tudo fica separado!
E quem gerencia seu funcionamento é o sistema operacional, multithreading quem deve gerenciar é o programador!

Então entendemos que um processo pode ter muitos threads.
Cada thread pode fazer uma coisa.
Se bem gerenciado pode se usar muitos thread e executar coisas em paralelo(literalmente).
Antes cada processo rodada na sua vez.
Agora cada thread pode rodar ao mesmo tempo!

Multithreading em sistemas com multiprocessadores é realmente muito mais difícil, já que você tem problemas de acesso simultâneo à memória de várias CPUs/núcleos e todos os problemas desagradáveis de sincronização de memória que surgem disso.

Uma única chamada de sistema pode criar mais de um thread
Threads compartilham dados e informações.
Threads compartilha regiões de instruções, globais e de heap. No entanto, ele tem seu registrador e pilha.
O gerenciamento de threads consome muito poucas ou nenhuma chamada de sistema devido à comunicação entre threads que pode ser obtida usando memória compartilhada.
É criado rapidamente, e termina mais rápido! Tornando barato sua criação.

Sabemos o que são threads, sabemos o que são processos. Entendemos que um processo pode ocupar vários núcleos permitindo
Multithreading, E cada processo tem sua vez de rodar.

Um thread é barato para criar e termina mais rápidamente que um processo!

Tenho que lembrar que isso é uma pincelada sobre o assunto. Existe muito mais coisas envolvidas das quais não coloquei aqui!

Fontes:
https://www.programacaoprogressiva.net/2014/09/Como-os-Processos-Sao-Executados-em-um-Computador.html

https://dev.to/nfo94/o-que-e-um-processo-em-um-sistema-operacional-2769

https://www.inf.ufpr.br/wagner/so/processos+threads.2pp.pdf

https://sites.google.com/site/proffernandosiqueiraso/aulas/5-processo

https://www.guru99.com/difference-between-multiprocessing-and-multithreading.html

https://acervolima.com/diferenca-entre-processo-e-thread/

https://acervolima.com/diferenca-entre-processo-processo-pai-e-processo-filho/

https://stackoverflow.com/questions/16116952/can-multithreading-be-implemented-on-a-single-processor-system

https://acervolima.com/diferenca-entre-processo-processo-pai-e-processo-filho/

https://www.inf.ufpr.br/wagner/so/processos+threads.4pp.pdf