Sei que vocês estão cansados de ver artigos e threads do tipo, mas vamos nesta 🧵 de 15 passos tentar dissecar algumas características primordiais de OOP através de uma simulação de OOP em, isso mesmo, Bash script.
OOP em Bash, a thread 👇
Se você não tem hábito em Bash script, não há problema.
Os conceitos aqui explicados não exigem conhecimento avançado de Bash, a ideia é apenas tentar entender e simular OOP.
Para implementar OOP, precisamos obedecer algumas regras elementares:
* ter uma forma de representar o estado do objeto
* permitir execução dinâmica de ações no objeto
Claro que há mais coisas envolvidas, mas estas 2 são primordiais para se ter um mínimo de OOP.
Com Bash, conseguimos cumprir estas 2 regras? Vamos tentar demonstrar aos poucos, começando pela primeira.
Criamos então uma estrutura (função, pois não existem classes em Bash) que irá representar o template de um objeto
Okay. Agora, vamos ver como seria a uma potencial utilização desta função para criarmos objetos.
Basicamente é passar argumentos para a função.
"$1": tipo do objeto
"$2": referência para o objeto
demais args: key-pair que deve representar o estado inicial do objeto
Para fazer este truque funcionar, a função Object deve iterar por todos os args e criar o estado do objeto.
Mas onde fica tal estado, uma vez que Bash não é OOP?
Podemos deixar no estado global do script (credo, eu sei), onde cada atributo precede com a referência do objeto
Okay, resolvemos a primeira regra, garantindo que o objeto tem um estado único e acessível (mas infelizmente global devido à característica léxica da linguagem).
E quanto à segunda regra, a ~execução dinâmica de ações no objeto~, ou comportamento?
Algo assim hipoteticamente:
Mas "chamar uma função" em um objeto não é possível, pois Bash não tem ~escopo léxico~, que é uma característica importante para que tenhamos o despacho dinâmico de mensagens em tempo de execução.
Entretanto podemos recorrer a outro truque.
Dá pra guardar a função em uma variável associada ao objeto, e *posteriormente* passar a referência desse mesmo objeto para a função, que será então executada.
Começamos por definir, na criação do objeto, um argumento a mais que representará o comportamento.
Então, definir a função em si que recebe a referência do objeto como primeiro argumento
Para então, modificar Object que agora também precisa saber fazer parse do argumento "fn_xxxx" que representa uma função do objeto, e guardar a referência da função em um atributo global de account (por isto o kind)
Com isto, podemos começar a criar objetos e chamar a função display neles.
Super YAY, mas dá pra melhorar isto.
Indo além, dá pra criar outra função chamada "Account", que será um wrapper para criação de objetos do tipo Account, assim dá pra agrupar todas as funções relacionadas à account dentro desta mesma estrutura.
Tá parecendo uma classe em OOP, não? :P
Implementação completa de Object
Agora, é só brincar com OOP em Bash
O código completo bem como uma explicação mais detalhada em inglês está neste Gist:
Não costumo dar dica de inglês pq não sou professor, mas tá aqui oq funcionou pra mim lá atrás qdo tudo era mato e não tinha internet nem dinheiro pra pagar cursinho de inglês.
Short🧵
(tldr; imagem já é pequeno spoiler)
Disclaimer
Assumindo que vc, assim como
eu, não nasceu com o c# virado pra lua e nao teve acesso a bons cursos de ingles com a devida frequencia. +
Basics
Pra correr atras do preju, esse livro é gold. Mesmo.
Ajuda a dar o up necessario na gramatica.
Cada pagina é uma lesson diferente com explicacao e exercicios. That’s enough, tudo oq nós mortais precisamos. Next.
Alguns ajustes no NGINX e PostgreSQL e minha versão Ruby ganha um aumento de tput que garante 46k inserts.
"Ajuste pra cima", eles dizem.
Não. É pra baixo.
As queries são rápidas, ñ preciso floodar a stack toda com mtos requests à espera: latência gera custo.
Detalhes na 🧵
TL;DR
- API com I/O assíncrono
- NGINX com 256 worker connections
- NGINX com least_conn para não jogar mais requests em upstream muito ocupado
- PostgreSQL com 30 max connections e tbm com 30 acessos simultâneos ao I/O
- Connection pool de 15 em cada API
Configuração do NGINX
Se eu abrir a torneira no NGINX pra sei lá, 10 mil conexões, ele vai tentar jogar o máximo possível no socket.
pessoal, apesar da zuera do Java não ter estado no TOP 15 da @rinhadebackend (kkkkk), queria deixar aqui algumas impressões sobre aspectos de concorrência em sistemas,
e que a natureza do desafio não coloca nenhuma lang em demérito, apesar da _zuera never ends_™️
as always, 🧵
quando um programa ou processo precisa realizar alguma computação, este é colocado pelo sistema operacional (SO) em uma fila,
tão logo a CPU fica disponível, o processo é atribuído à CPU e ganha uma fatia de utilização definida pelo escalonador do SO, que faz +
a troca de contexto entre diferentes processos na CPU.
processos não compartilham memória a princípio, e acontece que dentro de certos processos, podem ainda ser utilizadas outras estruturas menores de concorrência no SO, que compartilham memória, tbm chamadas de threads +
nesta pequena 🧵, iremos ver como utilizar xargs pra resolver o problema ali proposto pelo Seraphini. sem precisar de ferramentas adicionais, xargs funciona out-of the-box em qualquer sistema UNIX-based.
cada opção do comando será explicada ao detalhe 🔎 https://t.co/MLAVd4XLyI
Embora Tekton sirva para rodar o próprio CI no Kubernetes, os conceitos aqui apresentados podem ajudar a *entender melhor* de sistemas CI/CD no geral, inclusive os que trabalhamos no dia-dia, tais como Github, Gitlab, CircleCI etc
+
O primeiro foi uma introdução aos 3 principais componentes do Tekton: Step, Task e Pipeline.
São peças importantes que têm sua lógica fundamentada em diversos outros sistemas de CI/CD.