O que resolve um problema?

[ataxexe]

É engraçado quando pensamos em qual peça fundamental é responsável por resolver um problema.

Um exercício interessante é pensar como a humanidade conseguiu evoluir e conquistar o planeta. Isso só foi possível pela nossa capacidade de abstrair. A abstração possibilitou o surgimento de especializações e, assim, fomos progredindo.

Tá, eu sei que os dinossauros conquistaram o planeta e não sabiam abstrair, mas é um pouco diferente essa situação.

Voltando à minha mente doentia. Quando usamos boas abstrações, temos uma chance absurdamente alta de resolver o problema. Eu já cansei de ver soluções em busca de um problema pra resolver e já até me peguei usando recursos da linguagem pra resolver um problema só porque eu queria usar esse recurso.

O mundo tá cheio de boas abstrações como o V-Mail, que basicamente era uma fotografia das cartas que eram enviadas durante a Segunda Guerra. Infelizmente não faltam exemplos de abstrações que se provaram não ser eficientes pra resolver o problema a que se propuseram.

O Kubernetes, por exemplo, é uma baita abstração de um orquestrador. Um colega meu uma vez criou um player de música simples pra demonstrar como ele poderia ser usado pra orquestrar outras coisas que não fossem pods.

O JSF era uma abstração super interessante que infelizmente não pegou. Talvez pela forma complexa com que ele modelava a web naquela época, talvez pelo surgimento de frameworks action-based mais intuitivos e prazerosos de se usar. Me lembro de ter lido um tópico muito legal no GUJ sobre isso no tempo em que cloud só era termo técnico pra meterologistas.

Enfim, o ponto que quero chegar é: sempre pense nas abstrações antes de resolver um problema. A arquitetura de microserviços é um exemplo bem atual disso. No final das contas ela basicamente serve pra escalar pessoas e não código. É fundamentalmente um sistema distribuído e essa abstração está longe de resolver a maioria dos problemas em que é colocada à prova.

Pra variar, eu falo um pouco mais sobre isso no episódio novo do meu podcast. A quem interessar essa reflexão:

https://www.backpackcloud.com/right-in-the-middle/2021/07/28/look-ma-no-microservices.html

PS: Parece até que to usando a Taverna pra promover o podcast, na realidade eu não tenho saco pra isso, mas sempre acompanho o Kiko, desde os tempos de glória do GUJ, e sinto que aqui é um lugar legal pra jogar essas ideias no ar. No Twitter, LinkedIn e afins eu só posto o link mesmo. Aqui eu me sinto à vontade pra escrever alguma coisa sobre.

Abraços!

[kicolobo]

Que honra Ataxexe!

Sabe, parece que a gente tá sincronizado: hoje pela manhã estava pensando em algo nesta direção, como muitas vezes as pessoas que programam não chegam a boas soluções simplesmente pelo fato de… só pensarem em programar. Talvez soe grosseiro o que vou dizer, mas resumindo: devido à própria ignorância.

Pelo fato de se focarem apenas no computador e não em toda a cultura ao seu redor, que é justamente de onde surgem estes pontos que acabam por gerar as abstrações de onde surgem as soluções. To mais ou menos na mesma direção que você?

[ataxexe]

A honra é toda minha

É bem por aí mesmo, Kico. Eu acabei pontuando no podcast o fato de que, muitas vezes, as pessoas tendem a se ater às próprias expectativas e não às do negócio.

Então o fato de se usar X acaba não sendo pra atender uma necessidade de negócio e, sim, atender a uma necessidade pessoal.

Quando a gente muda o foco pra abstração e deixa as tecnologias amadas de lado, e, principalmente, quando queremos provar que estamos errados, a coisa flui muito melhor. Depois de entendermos o problema e mapear as abstrações necessárias, aí sim é uma boa hora de se pensar se aquela tecnologia tão querida provê tal abstração.

Um exemplo que lembrei agora: há mais ou menos uma década, eu trabalhei numa empresa que tinha uma segregação absurda entre teste e desenvolvimento. Era tão separada que até a base de código não era a mesma. Eram servidores SVN diferentes.

Eles criaram um plugin pro Eclipse pra fazer checkout de um branch e importar pra outro branch em outro SVN server (spoiler: travava mais que o Windows ME). Quando eu vi aquilo, fiquei chocado, instalei o git e fiz o trabalho que eles levavam dias pra fazer (imagine um merge sendo feito entre SVN servers diferentes) em questão de segundos (o cara que fazia o papel de integrador, ou seja, o coitado que tinha que fazer esses merges e sequer sabia programar, fez uma cara quando eu lhe mostrei que eu lembro até hoje). A abstração de repositório centralizado não atendia a necessidade do negócio deles. E fica pior, com a solução porca que eles criaram, ficou parecendo que o fato de terem alguns branches protegidos pra QA (no fim das contas era simplesmente isso que eles queriam) parecia uma péssima ideia.

Na verdade, tudo seria resolvido usando distribuição em vez de centralização. Por conta da ignorância ou medo do desconhecido, resolveram parafusar um prego.

[kicolobo]

A impressão que tenho é que se as pessoas olhassem menos para seus teclados e mais para o que há a sua volta teríamos coisas BEM mais legais.

Penso por exemplo no desenvolvimento do Macintosh original, em que uma série de elementos culturais foram parar ali: tipografia bonita por que o Jobs fez curso de caligrafia, excelente (pra época) áudio por que Jeff Raskin era músico, os ícones que vieram de Suzan Kare, artista plástica, até mesmo a simplicidade final da coisa que era influenciada pela cultura japonesa.

Sei não Ataxexe, cada dia que se passa minha preguiça dos que só olham pro teclado aumenta.

[kicolobo]

Tem dois livros (há mais, mas são os que mais me impressionaram) sobre isto.

do Steven Johnson, que mostra como os elementos culturais entram na interface das máquinas e vice-versa. É fenomenal.

E tem outro:

do David Gelernter, que mostra o aspecto estético da engenharia (estética era uma das minhas áreas de interesse quando fiz Filosofia (a outra era linguagem), por isto estes livros marcaram tanto)

[ataxexe]

Cara, nunca tinha pensado nessa dos que só olham pro teclado. Faz todo o sentido.

É interessante que eu comecei a refletir sobre meu modo de fazer as coisas. Eu geralmente tenho pouco tempo disponível fora do horário de trabalho, então eu acabo fazendo muita coisa de cabeça. Estruturo como deveria ser um programa que preciso codificar naquela meia hora antes de ir dormir, penso em como vou entregar um workshop enquanto tomo banho ou até mesmo meu próximo texto pro podcast. Ficar longe do teclado me ajuda demais a organizar as ideias. Eu acabo fazendo mais por “fazer menos”.

A verdade é que tudo melhora quando vira multidisciplinar. Eu lembro de ouvir quando era jovem o pessoal dizendo que ia pra exatas porque odiava português. Isso explica a quantidade absurda de relatórios de especialistas técnicos que não fazem o menor sentido.

Hoje eu vejo que várias coisas que aprendi ao longo dos anos que não tem nenhuma relação direta com a área de TI só me ajudaram a me diferenciar e impulsionaram minha carreira.

Vou colocar esses livros na minha listinha

[silvairsoares]

Por falar em sincronismo. Eu estava comentando como os meus colegas de trabalho aqui, sobre como é importante pesquisar antes de codificar.
Estávamos utilizando o Pool de Threads gerenciadas pelo .Net, para a execução de tarefas recorrentes dentro de uma API. Esta solução estava apresentando alguns picos de processamento e algumas falhas aleatórias difíceis de identificar. E o pior, só ocorria em produção.
Aí, em um belo momento, me deparo com este roadmap de tecnologias .Net, e uma sessão específica me chamou atenção: Task Scheduling.
Isto foi como uma lâmpada amarela sobre a minha cabeça!
Comecei a testar as opções, juntamente com um colega da equipe, e batemos o martelo sobre a utilização do Hangfire. E gente, que abstração fantástica! Ele gerencia a lista de trabalhos, podendo usar o MongoDB ou o próprio SQL Server (escolhemos o Mongo) e ainda te entrega um dashboard para acompanhar a fila de trabalhos sendo executadas, alertas e problemas ocorridos, dentre várias outras funcionalidades.
Aí, hoje, recebo um e-mail do resumo semanal do Taverna. Alguns minutos após eu comentar com os colegas do departamento, sobre como é importante utilizar abstrações, e sobre o fato de a maioria dos problemas que enfrentamos não serem novos problemas. Alguém, provavelmente já os enfrentou, criou soluções que já estão muito mais consolidadas, do que as nossas possíveis novas soluções.
Pesquisar é fundamental, antes de escrever código.