sábado, 28 de janeiro de 2017

FTP que se foi. Downloads que vamos ter.

A Internet, como conhecemos no passado e que foi a pedra fundamental do que temos hoje, não existe mais. =/

Vejo uns focos de resistência aqui e ali (quero acreditar que faço parte deles), mas... Mais cedo ou mais tarde, todos abandonam o barco de um jeito ou de outro, e cabe àqueles que ficaram dar continuidade (ou não).

O povo deve estar mais careca que eu =P de saber que tô desenvolvendo, nas horas vagas, uma tal de Confederação de Micro Serviços Retrô. O principal (pelo menos por enquanto) serviço é uma Search Engine para repositórios de arquivos (FTP principalmente, mas tem alguns em HTTP). E o conhecimento que eu obtive analisando diversos repositórios para construir cada Adapter para internalizar seus dados não me deixou feliz.

Com raras e honrosas exceções, os atuais mantenedores NÃO SABEM o que estão fazendo. Os melhores tentam não estragar nada, mas outros simplesmente rendem o serviço beirando o inusável. (sigh)

Um exemplo segue:

As Bibliotecas Digitais por excelência na Internet são os servidores FTP. Eles foram feitos pra isso: armazenar e servir arquivos, e o arquivo ainda é a principal (se não a única) mídia efetiva no mundo dos computadores e, por tabela, no mundo da Internet.

Existem outras formas de se servir arquivos? ô se tem. Mas quem tentou servir arquivos por HTTP sabe do tremendo trampo que dá manter a coisa escalável - ao mesmo tempo em que o FTP já tinha resolvido, há décadas, quase todos estes problemas!

É um protocolo "arcaico"? O motor à explosão também o é, e nem vou comentar sobre a roda. Não é porque é velho que deixou de ser útil, e não é porque é novo que é melhor! Se você não precisa de streaming, existe uma chance enorme de que o FTP, quando decentemente configurado, seja a melhor opção para você.

Uma reclamação recorrente que vejo nos fóruns dos atuais mantenedores de alguns repositórios é a largura de banda. Lógico que servir arquivos gasta largura de banda, e uma das formas que a geração anterior tinha para mitigar este problema eram os mirrors: "clones" do repositório oficial cuja função era fornecer alternativas para o download do arquivo. Você dá acesso privilegiado para os mirrors, acesso reduzido para o resto do povo, e publicava uma lista dos mirrors oficiais e o povo que se virasse.

Esta solução, no entanto, tinha um problema: a necessidade de se sincronizar os dados entre os repositórios para manter a consistência.

Profissionais competentes já pensam logo em RSYNC, e com razão.

Outros simplesmente ficam reclamando da largura de banda, impõem restrições e ofuscam endereços para "se proteger de leechers" - como se os dados sendo protegidos pertencessem à eles (simplesmente não é o caso na maioria das vezes).
Criar dificuldades para vender facilidades.
Mas os inteligentes vieram com uma alternativa mais barata: o ALLFILES.

Sempre que há uma alteração no repositório (arquivo que entra, arquivo que sai, arquivo atualizado), um processo noturno gera o ALLFILES (ou 00_INDEX.txt, ou ls-LR) com uma listagem de todos os arquivos do repositório. Alguns, mais sofisticados, usam este arquivo para fornecer uma descrição detalhada dos arquivos servidos - excelente para buscas.

Isso deixa tudo muito simples! Um mirror só precisa checar a data/hora da última alteração do arquivo (e, se for paranóico como eu, também o tamanho) e se for igual, não há nada o que fazer. Mas se for diferente, uma mera comparação com a cópia anterior é suficiente para se saber quais são as novidades e, então, tomar os passos necessários para atualizar sua cópia local.

Isso economiza recursos de todos os lados, porque não é necessário atravessar o repositório inteiro checando arquivo por arquivo!!

Então, ao invés de implantar QoS no seu servidor HTTPD, se preocupar com Load Balance, manter um banco de dados cuja única função é mascarar o endereço real do arquivo a ser servido (pra não falar nas constantes atualizações das páginas HTML quando muda o identificador do arquivo), gastar tempo e dinheiro com CAPTCHAs... E então se engajar numa batalha perdida contra Web Crawlers e serviços anti-capchas... Que tal voltarmos um pouco às nossas raízes?

É mais barato. É mais simples. É mais democrático. É mais Internet.

Pensem nisso.

quarta-feira, 4 de janeiro de 2017

Microserviços e Programação Estruturada - o tempo passa, mas não muda

Essa é só pros velhinhos. :-)

A long time ago, in a galaxy far, far away... A Programação Estruturada começava a pegar tração no Mercado (finalmente!). Estou falando de uma época que começou mais ou menos em 1978 e durou toda a década de 80.

Nesta época, ninguém sabia direito o que era esta tal de Programação Estruturada, muito menos os Gerentes que passaram a exigir que seus desenvolvedores passassem a aplicar isso do dia para a noite. Mas os artigos das Revistas Especializadas (que na época cumpriam o papel da Internet de hoje: propagar FUDs, tendências do momento e outras bobagens patrocinadas) explicavam tudo "direitinho", como segue:
Regras para Programação Estruturada
  1. Não usar GOTO
  2. Usar Procedures e Functions
  3. Cada Procedure e Function deve ter até 15 ou 20 linhas
  4. Declarar as variáveis antes de usá-las.
E então o que mais se via era programador pegando aquela maçaroca de código aestruturado (porque nem desestruturado aquilo era =D ), divindo o código em 20 linhas, colocando cada bloco de 20 linhas numa procedure (todas elas chamadas de proc1, proc2, proc3, etc...) e no corpo do programa, chamando as procedures em sequência. :-D

Ah, sim... E declarando todas as variáveis globais.

Hoje em dia isso parece piada, mas isso era realmente o cotidiano no Mercado por esta época. A Gerência simplesmente jogava o conceito na mesa e dizia "agora todo mundo faz assim" e dane-se.

O tempo passou, o Paradigma da Orientação à Objetos chegou e... Aconteceu a mesma coisa. Até hoje tem gente que se recusa terminantemente à usar OOP onde este paradigma é o mais indicado (e, diga-se de passagem, é a maioria dos sistemas de médio e grande porte).

E o tempo passou de novo, e nada mudou outra vez. É assim até hoje. :-)

A Nova Moda do momento são os Microservices. A coisa está tão elástica que, ao contrário da Programação Estruturada, não existe ainda nem mesmo um consenso sobre o que caracterizaria um Microservice. Mas estão todos embarcando na onda - inclusive eu! :-D

Correndo o risco de me tornar parte do problema, ao invés de resolvê-lo, seguem minhas impressões sobre o assunto:
  • Microservice é SOA. Se você não sabe o que é SOA, você não vai aprender o que é Microservice.
  • A mentalidade corrente ainda está fortemente amarrada ao paradigma anterior e arcaico, dos grandes Portais de serviços.
  • Microservice não é uma interface! Não estamos trocando o HTTP-RPC por outra coisa, não é isso!
  • As decisões de Arquitetura ainda estão fundamentadas nos paradigmas Cliente-Servidor clássicos. Usar Redis como repositório de dados de Microservices (substituindo SQL) pode ser um erro tão grande como usar SQL para guardar estes mesmos dados!
    • Um Microservice deve ser autocontido. Seu core business deve ser exclusivo, logo não há sentido em compartilhar seu core business usando outra interface que não a sua!
    • Se todos os dados do seu Microservice precisam estar compartilhados por outros Microservices, então possivelmente você caiu na armadilha do Nanoservice!
  • Segue a filosofia UNIX (cara programa deve fazer apenas uma coisa, e fazer muito bem feito), mas assim como este, é claramente incompreendido e frequentemente ignorado.
Ou, em miúdos, pegar a sua grande aplicação monolítica e sair criando uma camada em cima para "simular" microservices não é exatamente diferente de pegar uma maçaroca de linhas e dividir em procedures de 20 linhas acessando variáveis globais e chamar aquilo de Programação Estruturada! :-)

Microservice é um paradigma de Arquitetura, não de Implementação. Óbvio que a implementação segue a Arquitetura, mas deveria ser óbvio que o inverso não é verdade: não é porque você implementou um front-end de "Microserviços" que a sua arquitetura deixou de ser monolítica.

Este paradigma ainda é RiP (Research In Progress). Se você achou este artigo relevante, possivelmente vai ser interessar pelo meu Test Bed, a Confederação de Micro Serviços Retrô.  E sim, usei "Micro Serviços" e não "Microserviços" de propósito - não tenho tanta certeza de que estou de fato implementando Microservices, nem que vou ficar preso neste paradigma com o decorrer do tempo.  O objetivo da ferramenta é prover serviços para a comunidade de retrocomputação, se eles serão microservices ou não, é problema meu! :-)

sábado, 15 de outubro de 2016

Pareto foi Engenheiro Civil, não Analista de Sistemas

E ele nunca entregou um ferrovia com apenas 80% da construção concluída. #ficaDica
Vilfredo Pareto
Ele também foi sociólogo, filósofo, cientista político e economista. Por onde passou, deixou um legado de conceitos e princípios que são usados (e abusados) até hoje!
His legacy as an economist was profound. Partly because of him, the field evolved from a branch of moral philosophy as practised by Adam Smith into a data intensive field of scientific research and mathematical equations.
Entre suas contribuições (e foram muitas), destaco:

Distribuição de Pareto

  • É uma distribuição de probabilidade de Lei de Potência que atualmente é usada para descrever fenômenos sociais, científicos, geofísicos, atuariais e outros.
  • Se você não entendeu p* nenhuma, não se sinta só. Eu também não entendi muita coisa.
  • Foi usada por Pareto para seus estudos econômicos sobre distribuição de riqueza.

Ótimo de Pareto

  • O Ótimo de Pareto é um estado de alocação de recursos onde é impossível melhorar as condições de um indivíduo sem piorar as condições de outro(s).
  • Uma "Melhoria de Pareto" (Pareto Improvement) é quando um indivíduo tem seu estado melhorado sem o detrimento do estado de outro(s) indivíduo(s).
  • Não é uma classificação moral ou ética - é simplesmente o reconhecimento de um fato, a partir do qual outras decisões podem ser tomadas!

E o famoso Princípio de Pareto

  • Também conhecida como a regra do 80-20, distribuição A-B-C, lei dos poucos vitais ou  principio de escassez do fator.
  • A que darei destaque abaixo.
Logo de cara, um leitor atento notará que dos links acima, apenas um está em português, justamente o Princípio de Pareto - e isso já dá o tom do que virá pela frente. Todos os demais artigos não foram traduzidos, ou estão apenas germinados, resumidos e sem fontes confiáveis (de acordo com a Wikipedia) em nossa língua.

Não fiquei surpreso pela falta de interesse do lusófono em se informar sobre estes assuntos... Estudar a Distribuição da Riqueza, ou buscar evitar situações de soma zero não costuma fazer parte de nossas preocupações - mas isso em si já é assunto para outro post (possivelmente em outro blog!).

Hoje, eu falo sobre o Princípio de Pareto, e dos efeitos terríveis que a aplicação burra e cega da sua máxima vem causando na economia e no futuro da Tecnologia da Informação - ou... Como burros motivados, lendo apenas *uma linha* da teoria, a saem aplicando ad nauseam sobre qualquer pretexto, desde que para livrar seus ignóbeis rabos de merecido destino.

Pausa Dramática para troca de Cenário

Após uns 8 meses de trabalho (e retrabalho) insano, ficou óbvio que o Novo Sistema™ não ficaria pronto dentro do prazo acordado com o então Futuro Cliente. Pior, os esforços de desenvolvimento estavam prejudicando a manutenção do Sistema Legado™ - que apesar de todos os problemas (que não eram poucos), era o que convencia os então Presente Clientes a pagarem nossos salários no fim do mês.

Reuniões, Planos de Contingência, e então o golpe fatal: o cara usou Pareto.

Para entender o tamanho do sacrilégio - e o motivo pelo qual o cadáver de Signore Vilfredo provavelmente deu mais voltas dentro em seu caixão que a Lua em volta da Terra, permita-me a Platéia uma breve explicação.

O Princípio de Pareto afirma que, para muitos eventos, cerca de 80% dos efeitos vêm de 20% das causas, observação feita enquanto na Universidade de Lausanne em 1896, conforme publicado em seu primeiro papel, "Cours d'économie politique". Essencialmente, Pareto mostrou que aproximadamente 80% das terras em Itália era de propriedade de 20% da população: Pareto desenvolveu o princípio pela observação de que cerca de 20% das vargens no seu jardim continha 80% das ervilhas.

Posteriormente, e por vários autores, estendeu-se o Princípio observando-se que 80% das vendas de um negócio costuma vir de 20% dos clientes; que 80% dos problemas de um empreendimento de engenharia advém de 20% de causas comuns; que 80% dos problemas de um software estão relacionados à 20% dos requisitos; e por aí vai.

As duas últimas afirmações levam à um interessante corolário: a de que detectar e sanar os tais 20% de causas eliminam 80% dos problemas que infernizam o projeto, mitigando seus riscos!

Um vez esclarecido o assunto, voltemos ao nosso roteiro original: o cara usou Pareto.

Através de um intenso processo de racionalização descolada da realidade (nenhum sistema lógico é válido, por mais sonora que seja a corretude dos processos, se seus axiomas são falsos!), concluiu-se que deveríamos tratar 80% dos problemas que estivessem afetando os 20% maiores clientes e então estaríamos protegidos pelo Cânone Metafísico de Pareto - a variante sobrenatural do Princípio que afirma que recorrer ao Signore Vilfredo em nossas preces, digo, estratégias garante-nos sucesso divino.
Como se os 20% maiores clientes da empresa estivessem pagando apenas 80% da tarifa - ou se não precisássemos dos demais 80% dos clientes para ter lucro no fim do mês.
E foi assim, prezados, que o então Futuro Cliente se tornou Presente Cliente de outrem, bem como boa parte daqueles nossos 80%. Não tenho a menor dúvida que fizemos felizes 100% de nossos concorrentes.

Quem paga 100% da tarifa quer 100% do serviço/produto/whateverPONTO. Entregar 80% do acordado não é uma estratégia sustentável de captação e fidelização de clientes.

E, por fim, você não quer que aqueles tais 20% se tornem 100% da sua clientela. Confiem neste que vos narra, eles são a causa de 80% dos seus problemas. :-)

segunda-feira, 10 de outubro de 2016

Vaidade, vaidade - Tudo é vaidade...

O que há com esta geração com menos de 30, 35 anos? Possuem uma autoestima tão exacerbada (ou uma baixa autoestima tão patológica que precisam provar à todos o tempo todo o quanto se amam) que são incapazes de reconhecer que existe coisas mais importantes que eles próprios?

Então um mantenedor de um projeto interesse cai no lado negro dos mantenedores de um outro projeto do qual o cara era fã - ele construiu algo tão bacana quanto, e os carinhas ficaram de mau e não o chamaram mais para as festinhas.

Ok. Sacanagem. Alijaram ele de uma Comunidade, e propaganda é a alma do negócio.

Mas daí o cara vai lá e derruba o projeto dele, porque ele não se sente bem fazendo algo que promova o projeto dos carinhas que machucaram seu coraçãozinho...

Crianças, aprendam com o titio Lisias: amor, amizade e acolhimento se procura de quem lhe ama, lhe tem apreço e gosta de você.
Com o resto, você convive e colabora em troca de um benefício mútuo - e se você gosta dos caras ou eles de você é, francamente, irrelevante. Ótimo se rolar, mas irrelevante assim mesmo.

Quando você derruba um projeto grande porque não quer mais jogar confete nos seus desafetos, você não está cuspindo nos seus desafetos, mas nos seus usuários. São eles que ficaram sem o projeto, são eles que confiaram em você e por isso ficaram na mão.

Se você mija em todo mundo porque uns poucos mijaram em você - isso não te faz alguém algumas ordens de magnetude pior que eles? 

domingo, 25 de setembro de 2016

Unit Testing - Ou como jogar tempo e dinheiro fora e ainda ir pra casa com a sensação de Dever Cumprido.

Fonte. Giphy.
Testes de Unidade.

Que invenção maravilhosa - todos os mais comuns erros detectados antes mesmo do push.

Ficaram no passado as longas horas de debugging, o tempo desperdiçado escrevendo documentação, os recursos desviados fazendo testes de aceitação antes do deploy.

Só que não. :-)

Há long time ago, in a job far, far away eu fiz parte de um time de desenvolvimento bem interessante. A diversidade de talentos e níveis de experiência era bem alta (o que é bom!!!), mas por outro lado, a consolidação de uma cultura rígida e dogmática num ambiente dito ágil levava regularmente ao uso... pouco ortodoxo... das práticas da metodologia que achavam que estavam aplicando.
Paradoxal? Com certeza! Participei de equipes sob RUP bem mais flexíveis!
Uma destas práticas era o Teste de Unidade.

Quase 50% do esforço de desenvolvimento era gasto em Testes de Unidade, numa tentativa de se economizar esforço em Documentação e Requisitos. O Código era a Documentação, e havia um "Teste de Unidade" para cada Use Case.

A teoria até que faz sentido - é fato que, no primeiro gargalo, a documentação é a primeira vítima porque os recursos são desviados para onde se efetivamente agrega valor ao produto, código. Mas existe uma coisa chamada Requisito Não Funcional, e isto não se documenta com eficácia num Teste de Unidade.

Pior, Testes de Unidade também são código, e portanto acabam duplicando o esforço de programação quando um Requisito Funcional acaba tendo que ser mudado - o que leva à uma resistência dos gestores em admitir mudanças em features já implementadas (afinal, vai custar o dobro!) e... bom... acaba sufocando o principal objetivo da Metodologia, que é a agilidade.
Alguns Requisitos são mais baratos de serem mantidos com o trio Documentação, Teste e Código (esta tríplice aliança ainda será discutida neste blog!) - há mais profissionais disponíveis na empresa capacitados nos dois primeiros que no último (pense nisso!).
O pessoal chegava à um nível de detalhamento absurdo - fazendo Testes de Unidade para o CRUD no banco de dados! Vá pra porra, se você não confia no BD e/ou no framework (afinal, estes componentes possuem seu próprio ciclo de vida e foram aprovados em algum momento, não?), então você não deve usá-los em produção e ponto final!

Isso adicionalmente causava um overhead de (estou chutando) 10 a 15% no tempo de processamento dos Testes de Aceitação e, pior, davam uma sensação de falsa segurança - porque a quantidade enorme de pequenos Testes De Unidade (que não testavam o core business da aplicação) que nunca falhavam mascaravam as fragilidades no Controle de Qualidade.

Um exemplo clássico e trágico é a historiazinha que segue:

A Aplicação Web em questão tinha uma estratificação entre os clientes: aqueles que consumiam muito mais conteúdo que geravam (quando o faziam), e os que geravam muito mais conteúdo do que consumiam. Óbvio que era vital para o Product Owner evitar situações (sejam técnicas ou políticas) que pudessem boicotar a facilidade com que o conteúdo pudesse ser consumido, mas principalmente ele precisava à todo custo desemperrar qualquer empecilho à criação deste conteúdo (sem os poucos que geraram conteúdo, não haveria o que consumir pelos demais clientes).

A Aplicação, então, tinha (entre outras, lógico), duas Health Metrics: a quantidade de usuários cadastrados, e a quantidade de conteúdo no sistema.

Parece óbvio. Era óbvio. Mas ainda assim....

No meio daquela mar de Testes de Unidade, ninguém se deu ao trabalho de fazer um Teste que garantisse que as métricas de conteúdo fossem corretamente atualizadas no Painel de Controle do Product Owner. Só isso. :-)

O P.O. tinha na mão as Histórias implementadas, e a informação de que os Testes de Unidade estavam todos sendo executados com 100% de aprovação. E confiou nisso (era responsabilidade da Equipe garantir a integridade dos Testes, não dele!).

Um belo dia, uma crise política qualquer (que, falemos francamente, é cotidiana - todo mundo adora um drama, e a concorrência óbvio que usa isso para fatiar o mercado e tirar o dela), ocorreu uma debandada de usuários. Já havia acontecido este #mimimi antes, e a crise tinha sido superada identificando, pelas métricas, quais grupos de usuários estavam debandando, e então mitigando pontualmente as causas.

Mas desta vez, o P.O. não conseguia acertar a mão. Nada do que ele fazia parecia dar certo. Levou-se umas duas semanas (se a memória não me falha) para se detectar o que estava acontecendo, e neste momento o estrago estava grande o suficiente para comprometer os objetivos estratégicos da empresa com a aplicação.

O que aconteceu é que, por questões de "performance", as métricas de conteúdo não estavam sendo atualizadas automaticamente (ou com a regularidade necessária, não lembro mais ao certo). O P.O. sabia que estava perdendo consumidores (porque estas métricas estavam funcionando), mas como as métricas de conteúdo estavam artificialmente boas, ele concluiu que precisava atuar na captação de consumidores, quando na verdade o problema é que ele precisava desesperadamente trabalhar para evitar o sangramento de produtores!!!

Do meu ponto de vista, a falha aqui foi a absoluta falta de preocupação com os Testes de Integração, necessários para garantir a corretude da implementação das Histórias. Achou-se que os Testes de Unidade eram suficientes, e ninguém empregou esforços para garantir a completude e corretude das Histórias.

O aftermath foi que, por estes e outros motivos, quando eu fui pedir ao gestor minha transferência da equipe (porque, francamente, eu já não confiava mais nela), fiquei sabendo que o P.O. também havia pedido a cabeça da equipe. :-D

O que aconteceu depois é papo para outra oportunidade. Hint: eu consegui o que pedi, mas não da forma que eu desejava! ;-)

sexta-feira, 25 de novembro de 2005

Uma história de Churchill

Um dos problemas mais básicos, mas infelizmente mais comuns neste nosso Brasil varonil é Liderança. Não, não falo de Autoridade (que isto temos à exaustão) : temos chefes de sobra. O que falta são Líderes.

Sempre fui um entusiasta da História da Segunda Guerra Mundial, e talvez seja por este motivo que os problemas de liderança acabem por me envolver tanto : foi na Segunda Grande Guerra que os exércitos ocidentais começaram à reavaliar suas operações - reavaliação esta que levou, inclusive, ao grande avanço no planejamento e execução de projetos de larga escala (interessados, procurem a história do projeto do submarino Polaris).

Não é casual, então, que o primeiro post real deste blog começe com uma história sobre Winston Churchill - sem dúvida o homem cuja Liderança foi capaz de unificar o mundo contra a ameaça nazista (principalmente porque tudo o que o mundo ocidental queria ver, então, era a "oportunidade nazista" para fazer novos negócios!).

Chega de lero-lero. Vamos ao que interessa.

O MEDO CAUSADO PELA INTELIGÊNCIA

Quando Winston Churchill, ainda jovem, acabou de pronunciar seu discurso de estréia na Câmara dos Comuns, foi perguntar a um velho parlamentar, amigo de seu pai, o que tinha achado do seu primeiro desempenho naquela assembléia de vedetes políticas. O velho pôs a mão no ombro de Churchill e disse, em tom paternal:

"Meu jovem, você cometeu um grande erro. Foi muito brilhante neste seu primeiro discurso na Casa. Isso é imperdoável. Devia ter começado um pouco mais na sombra. Devia ter gaguejado um pouco. Com a inteligência que demonstrou hoje, deve ter conquistado, no mínimo, uns trinta inimigos. O talento assusta."

E ali estava uma das melhores lições de abismo que um velho sábio pode dar ao pupilo que se inicia numa carreira difícil. A maior parte das pessoas encasteladas em posições políticas é medíocre e tem um indisfarçável medo da inteligência. Isso na Inglaterra. Imaginem aqui no Brasil. Não é demais lembrar a famosa trova de Ruy Barbosa:

Há tantos burros mandando
Em homens de inteligência
Que às vezes fico pensando
Que a burrice é uma Ciência.

Temos de admitir que, de um modo geral, os medíocres são mais obstinados na conquista de posições. Sabem ocupar os espaços vazios deixados pelos talentosos displicentes que não revelam o apetite do poder. Mas é preciso considerar que esses medíocres ladinos, oportunistas e ambiciosos, têm o hábito de salvaguardar suas posições conquistadas com verdadeiras muralhas de granito por onde talentosos não conseguem passar.
Em todas as áreas encontramos dessas fortalezas estabelecidas, as panelinhas do arrivismo, inexpugnáveis às legiões dos lúcidos.

Dentro desse raciocínio, que poderia ser uma extensão do Elogio da Loucura de Erasmo de Roterdan, somos forçados a admitir que uma pessoa precisa fingir de burra se quiser vencer na vida. É pecado fazer sombra a alguém até numa conversa social. Assim como um grupo de senhoras burguesas bem casadas boicota automaticamente a entrada de uma jovem mulher bonita no seu círculo de convivência, por medo de perder seus maridos, também os encastelados medíocres se fecham como ostras à simples aparição de um talentoso jovem que os possa ameaçar.

Eles conhecem bem suas limitações, sabem como lhes custa desempenhar tarefas que os mais dotados realizam com uma perna nas costas, enfim, na medida em que admiram a facilidade com que os mais lúcidos resolvem problemas, os medíocres os repudiam para se defender. É um paradoxo angustiante.

Infelizmente temos de viver segundo essas regras absurdas que transformam a inteligência numa espécie de desvantagem perante a vida.

Como é sábio o velho conselho de Nelson Rodrigues: finge-te de idiota e terás o céu e a terra.

O problema é que os inteligentes tem ego muito desenvolvido, gostam de brilhar. Que Deus os proteja.

José Alberto Gueiros.
JORNAL DA BAHIA - Sábado , 23/09/79

Limitar a aplicação dos conceitos expostos neste artigo apenas à Indústria de T.I. (foco deste blog) é claramente injusto - é óbvio que isto ocorre para todos os lados.

Mas além do óbvio fato da T.I. ser minha área de atuação e, portanto, a única da qual eu posso falar com conhecimento de causa, a Tecnologia da Informação possui uma característica singular, que a torna um "Objeto de Observação" ímpar: por ser uma indústria volátil e dependente de bons resultados de curto prazo, Empresas de T.I. enfrentam ciclos de apogeu, glória e amarga decadência que chegam a durar parcos 3 ou 4 anos! É uma indústria inclemente, onde um erro crasso apenas pode sublimar todos os sucessos de um passado recente...

E eis, portanto, que os "nossos medíocres" não ficam muito tempo no poder - faz-se (e vira-se) história muito rápido neste ramo.


Se isto é bom ou ruim, não tenho (ainda) opinião formada...

Levando em consideração o grau de especialização e raciocínio lógico necessário para se estabelecer nesta área, quero crer que muitos destes "medíocres" são pessoas inteligentes que apenas são ainda por demais inseguras e inexperientes para abandonar as táticas "medíocres" mas confortavelmente seguras pelas práticas que realmente trazem resultados (e um bocado de insegurança).
Insegurança e inexperiência cujas raízes estão, à meu ver, na (incrivelmente) longeva batalha entre o Bom Senso (eterno perdedor) e o (Mau) Senso Comum que insiste em fundamentar sua razão nos três Non Sequitur's mais perniciosos da Cultura Ocidental:

Pela inseguranga, perpetua-se a inexperiência - que consolida a ignorância. Da ignorância, nasce o medo - que por sua vez retroalimenta a insegurança... E é deste círculo vicioso que vive a Mediocridade.

Que por sua vez tem causado desperdícios formidáveis - na Educação, na Política, na Indústria, na Saúde, e até mesmo no núcleo familiar: o que torna o combate à Mediocridade um dever cívico.

Solenemente ignorado...

terça-feira, 2 de agosto de 2005

Respeitável Público !!

Sede bem-vindos!
Pois começa, aqui e agora, a Grande Comédia; a trágica e cômica história de um pobre mortal que, sem saber o que fazia, aventurou-se nas artes arcanas da Tecnologia da Informação e lá perdeu-se.
Mas por que "Baudeville"?
Baudeville possui dois significados, não necessariamente mutuamente exclusivos:

Baudville foi uma Software House dos anos '80. Ela produziu alguns dos melhores softwares que já rodei no meus legendários Apple ][ e Apple //e. As Software Houses dos anos '80 são as predecessoras das atuais e pretensas "Fábricas de Software" - que alguns imaginam serem capaz de implementar sem saberem o mínimo sobre o funcionamento de uma Indústria.
É, também, a junção de dois termos, estes sim distintos:

  • Baud : Unidade de medida de transmissão de dados modulados em onda por segundo. Um Baud é uma mudança na modulação por segundo. Nos primórdios da comunicação digital se transmitia exatamente 1 bit por baud - meu primeiro modem era de 1200 Bauds - ou seja, 1200 mudanças na fase da onda por segundo. Hoje em dia os modens são capazes de transmitir vários bits por Baud.
  • Vaudeville : Um estilo teatral norte-americano de vários atos, cujo apogeu se deu entre 1880 e 1920. Era essencialmente uma salada de atos, vairando de malabarismos a shows de mágica, musicais e exibições matemáticas, números com animais, opera, ginástica, atletismo e até palestras de poetas e intelectuais.
Este blog é, então, uma homenagem a um modelo de produção de software comercial onde o importante era entregar um software útil e usável, um software que resolvesse problemas (ao invés de criá-los!). É uma apologia ao tempo em que o importante era satisfazer o cliente (até porque ele tinha a opção de procurar um software equivalente em outra Software House!!), e não seguir regras obscuras que uns poucos iluminados (que pouco ou nada têm de experiência em construção de software!!) julgam (nem sempre erroneamente, admito) adequados.
Neste Baudeville, a distinta platéia rirá, vibrará e emocionar-se-á assistindo a miríade de personagens, malabarismos e histórias (algumas da carochinha...) nos quais, para o seu deleite, este grande teatro tragicômico chamado Tecnologia da Informação se inspira.

(c)2005 a 2016 por Lisias Toledo.
Reproduções parciais autorizadas somente com menção da fonte e com fins não comerciais.
Qualquer outra utilização, comercial ou não, somente com autorização expressa do autor.