quarta-feira, 30 de julho de 2025

Watson, z17 e o que é REAL na IA moderna

 


🧠 IA no IBM Mainframe

Watson, z17 e o que é REAL na IA moderna (sem papo de slide)

“Mainframe não virou GPU.
Mas virou ponto de decisão inteligente.”


🧬 Antes de tudo: o que NÃO é IA no Mainframe

Vamos matar os mitos logo no começo:

❌ O z/OS não é uma plataforma para:

  • Treinar LLMs

  • Rodar TensorFlow pesado

  • Substituir GPUs

  • Concorrer com data centers de IA

❌ O Watson não é um “ChatGPT rodando em COBOL”.

❌ O z17 não é um supercomputador de deep learning.

👉 Quem diz isso nunca rodou produção bancária.


🧠 Então… o que É IA no Mainframe?

IA no mainframe é:

Inferência próxima ao dado
Decisão em tempo real
Baixa latência
Alta segurança
Governança forte
Explicabilidade

IA no mainframe não pensa muito.
Ela responde rápido, certo e auditável.


🤖 IBM Watson: o que ele é DE VERDADE

📜 Origem rápida

  • Watson nasceu em NLP e análise cognitiva

  • Ficou famoso no Jeopardy

  • Evoluiu para:

    • NLP

    • Classificação

    • Extração de entidades

    • Análise de texto

    • Modelos treinados sob demanda

🧠 Watson HOJE

Watson hoje é:

  • Um conjunto de serviços de IA

  • APIs

  • Modelos especializados

  • Integrável com mainframe

⚠️ Watson não substitui modelos open source modernos
Ele é usado quando:

  • Compliance é obrigatório

  • Dados são sensíveis

  • Explicabilidade é exigida

  • Contratos regulatórios mandam


🔌 Watson + Mainframe: como se conectam

Arquitetura real:

COBOL / CICS | | REST / MQ / gRPC | Watson (Cloud / Hybrid) | | Score / Classificação | COBOL decide



Exemplos reais:

  • Classificação de documentos

  • Análise de reclamações

  • Score de risco

  • Detecção de fraude textual

  • Triagem automática

O Watson opina
O COBOL bate o martelo


⚙️ z17: o que ele traz para IA (sem ilusão)

Agora vamos ao ferro.

🧱 O z17 NÃO foi criado para treinar IA

Ele foi criado para:

  • Rodar inferência com latência mínima

  • Executar decisões junto aos dados

  • Segurança embarcada

  • Escala transacional absurda


🧠 O grande trunfo: IA “perto do dado”

O z17 permite:

✔ Rodar modelos no Linux on Z
✔ Usar containers (zCX)
✔ Chamar IA sem sair do ambiente seguro
✔ Reduzir tráfego de dados sensíveis

Dados financeiros não gostam de passear na internet.


🔐 IA com segurança de mainframe

Isso o z17 faz melhor que qualquer cloud genérica:

  • Criptografia por hardware

  • Isolamento extremo

  • Compliance (PCI, GDPR, LGPD)

  • Auditoria forte

  • Zero Trust real

IA + mainframe = IA domesticada 🐕


🚀 Onde o z17 BRILHA na IA moderna

1️⃣ Inferência em tempo real

  • Fraude

  • Crédito

  • Risco

  • Limites

  • Compliance

2️⃣ Decisão transacional

  • CICS chamando modelos

  • Batch enriquecido com IA

  • Score inline

3️⃣ Governança

  • Logs

  • Rastreabilidade

  • Explicação de decisão

4️⃣ IA como serviço interno

  • APIs internas

  • Microserviços

  • Sem expor dados críticos


❌ Onde NÃO usar IA no z17

  • Treinar modelos grandes

  • LLMs gigantes

  • Experimentação pesada

  • Data science exploratório

Isso é para cloud com GPU.
E tudo bem.


🧩 Arquitetura moderna REAL (não de palestra)

[ Apps / Canais ] | [ APIs / Gateway ] | [ IA (Cloud GPU) ] <-- Treino | [ Model Registry ] | [ z17 - Inferência ] | [ COBOL / CICS / DB2 ]



✔ Treina fora
✔ Inferência dentro
✔ Decisão no COBOL


🧙 Easter-eggs de veterano

  • Mainframe não quer ser “inteligente”

  • Ele quer ser confiável

  • IA erra

  • COBOL não pode errar

  • Regulador confia no COBOL

  • Auditor confia no log

  • Cliente confia no dinheiro certo


🛣️ Caminho do padawan moderno

Se você quer ser relevante:

Aprenda:

  • COBOL moderno

  • APIs no mainframe

  • Linux on Z

  • Containers

  • Integração com IA

  • Governança de decisão

Não aprenda:

  • “COBOL morreu”

  • “IA resolve tudo”

  • “Vamos jogar tudo pra cloud”


☕ Palavra final do El Jefe

IA é cérebro auxiliar.
Mainframe é sistema nervoso central.

O Watson ajuda.
O z17 acelera.
O COBOL decide.

E quem decide…
manda no dinheiro do mundo 💰

segunda-feira, 28 de julho de 2025

Os principais fetiches dos animes e seu significado psicológico

 

Os principais fetiches dos animes e seu significado psicológico

O universo dos animes sempre explorou elementos sensoriais e simbólicos que despertam curiosidade e atração no público. Muitas vezes, o que chamamos de “fetiche” não se refere apenas a desejo sexual direto, mas a um conjunto de arquétipos visuais e comportamentais com raízes psicológicas profundas no imaginário coletivo japonês e mundial. Estes recursos, quando utilizados com intenção narrativa, podem construir personagens memoráveis, destacar temas culturais e até provocar reflexões sobre identidade e fantasia.

A seguir, apresenta-se uma análise de alguns dos fetiches mais comuns na indústria de anime, acompanhada de suas interpretações psicológicas e exemplos representativos.


1. Maid (empregadas)

Significado psicológico: idealização do cuidado, submissão consentida e fantasia de atenção dedicada.
A figura da maid simboliza conforto emocional e refúgio na rotina. Nos animes, costuma reforçar dinâmicas de poder assimétrico que geram conforto ao espectador.

Exemplos: “Kaichou wa Maid-sama!”, “Re:Zero” (Rem e Ram).

Curiosidade: o Japão possui cafés temáticos chamados maid cafés, que performam a estética da “serva perfeita”.


2. Tsundere

Significado psicológico: fascínio pelo desafio emocional.
Personagens que alternam hostilidade e afeto ativam o fenômeno de recompensa intermitente, comum em dinâmicas sentimentais reais.

Exemplos: Taiga (“Toradora!”), Asuka (“Neon Genesis Evangelion”).

Comentário: o fetiche reside na conquista. A afeição não é gratuita, ela precisa ser “merecida”.


3. Orelhas e traços animais (Kemonomimi)

Significado psicológico: atração pela dualidade inocente e selvagem.
A mistura de humano e animal sugere espontaneidade, pureza e instinto, além de criar personagens mais expressivos.

Exemplos: Holo (“Spice and Wolf”), Raphtalia (“Tate no Yuusha”).


4. Óculos (Meganekko / Meganekko boy)

Significado psicológico: idealização da inteligência, disciplina e mistério.
O acessório simboliza controle racional, o oposto da impulsividade emocional.

Exemplos: Gendo em “Evangelion” dentro do arquétipo masculino mais rígido; muitas heroínas de slice of life que representam seriedade ou timidez.


5. Uniformes escolares

Significado psicológico: nostalgia e romantização da juventude.
O público adulto associa essa estética a um período de descobertas e romances idealizados.

Exemplos: praticamente toda a mídia de romance escolar como “Your Lie in April” e “Kimi ni Todoke”.

Reflexão cultural: a idealização excessiva da adolescência é recorrente no entretenimento japonês.


6. Dominação e submissão (Master-Servant, Magical Contracts)

Significado psicológico: fantasias de controle e entrega emocional.
Relacionamentos onde um personagem depende do outro reforçam a busca por estabilidade e pertencimento.

Exemplos: “Fate/stay night” (Mestre e Servos), “Black Butler”.


7. Garotas Monstro (Monster Girls)

Significado psicológico: o fascínio pelo exótico e proibido.
Mistura medo e atração. O desconhecido se torna objeto de fantasia.

Exemplos: “Monster Musume”, “High School DxD” em alguns aspectos.


Por que esses fetiches permanecem tão populares?

  1. Reforçam vínculos emocionais com o público: quanto mais simbologia, maior a identificação.

  2. Facilitam a criação de personagens instantaneamente reconhecíveis: o fetiche serve como “atalho narrativo”.

  3. Conectam fantasia e realidade: escapismo cultural diante de pressões sociais, especialmente no contexto japonês.

  4. Evoluem conforme as gerações: arquétipos antigos ganham roupagens novas.


A fronteira entre representação e hipersexualização

Embora muitos desses elementos tenham função narrativa legítima, o uso excessivo pode desviar o foco da história, reforçar estereótipos limitadores ou normalizar fantasias problemáticas sem questionamento. A crítica especializada discute constantemente o equilíbrio entre expressividade estética e exploração comercial.

Quando um fetiche se torna dominante ao ponto de ofuscar tudo ao redor, perde complexidade e vira apenas um mecanismo para prender atenção. O desafio dos roteiristas consiste em usar símbolos que acrescentem significado, não apenas estímulo visual.

Por que chamamos isso de fetiche?

Porque tais elementos não são apenas características visuais. Eles ativam respostas emocionais automáticas:

Gatilho narrativoResposta emocional típica
Inocência + atraçãoProteção e empatia
Mistério + controleFascínio e curiosidade
Rebeldia + transformaçãoDesejo de conquista emocional

Mesmo quando existe componente sensual, ele costuma ser mediado pelo humor ou pela fantasia estilizada.


A linha tênue: fetiche vs. sexualização problemática

O consumo acrítico pode gerar terreno para exageros e distorções. Questões como:

  • Sexualização de personagens menores de idade

  • Estereótipos de gênero repetidos sem reflexão

  • Fetichização de traumas como entretenimento

Tais situações alimentam críticas legítimas da comunidade e da mídia.

O ponto central de qualquer análise é contexto e intenção. Quando é símbolo narrativo, pode enriquecer. Quando reduz personagens a objetos, empobrece.


Conclusão

Os fetiches nos animes revelam tensões sociais, fantasias coletivas e necessidades emocionais humanas, não apenas estímulos superficiais. Compreender essas manifestações de desejo simbólico ajuda a observar a produção otaku com mais maturidade, sem ignorar dilemas éticos que permanecem em debate.

domingo, 27 de julho de 2025

A grande confusão do Software Legados em mini tópicos.

 Newsletter Logo

Bellacosa Mainframe fala sobre a confusão dos software legado

A grande confusão do Software Legados em mini tópicos.

4,385 followers

Descubra o que é Software Legado

Salve jovem padawan, Fevereiro continua com muita chuva, a quarentena nunca mais acaba e o tiozão aparece com mais um artigo, originalmente pretendia ir diretamente para meu projeto mainframe, mas surgiu um gancho sobre metodologias, que puxou um fio e o novelo se desenrolou, necessitando falar sobre um tópico cavernoso.

As vezes pensamos em seguir um rumo, mas lendo os comentários no Fórum, vejo alguns Dionitos indignados, com bases frágeis, então acabo escrevendo um novo artigo com tópicos que espero de coração ajudar.

Sem mais delongas, vamos falar sobre Software Legado, passando por histórias de antigos CPDS e seus Spaghetti Code, Monólitos, Software Quebrados e explorando abertamente o conceito de software Legado.


O que é Software Legado?

É uma expressão muito utilizada para designar Sistemas Informáticos antigos, mas que continuam em operação, atualmente tem um sentido pejorativo, em que as novas gerações de DEVs acostumados a Frameworks de Trabalho com muitas cores, sons e imagens, acabam desdenhando destes sistemas, por acreditarem em coachs e empresas de consultoria, que aspiram vender pacotes de serviços.

Claro que muitas vezes realmente são softwares monolíticos construídos sem nenhum cuidado, cheios de remendos e tecnologias obsoletas, que nem valem o trabalho de migração, devendo ser jogados na lata do lixo da empresa.

Mas na maior parte do tempo, são softwares em produção, gerando milhões de lucro a seus stakeholder, administrando base de dados com milhões de registros, muitas vezes a engenharia envolvida em sua construção, mantem softwares performáticos, econômicos em uso de espaço em disco e memória, em sintes obras de arte em bits e bytes, programas que exploram o máximo da logica matemática, com escrita elegante e codigo limpo-


Modas e modismos

Os avanços tecnológicos criam necessidades aos usuários, que por sua vez pressionam a área de informática a criar soluções para as atividades do dia a dia na empresa, trabalhei com um gestor, que sempre argumentava ao final deste pedido, a sua produtividade ira aumentar quantos por cento? O break-even deste investimento será em quantos meses?

O grande receio era tornar-se vítima de modismo e gastar recursos vitais em projetos sem relevância e perigosos para o negócio da empresa. Os ERPs são um grande exemplo deste problema, totalmente em voga nos anos 90, hoje tornaram grande monstros legados, mantidos por analistas a beira da reforma, muitas das empresas desenvolvedoras foram incorporadas a grandes grupos, restando meia dúzia delas.

Outro exemplo da virada do século, as grandes empresas utilizam Mainframe com seus terminais 3270 ou emuladores em redes de cabo coaxil, atendiam a necessidade e geravam poucas transferências de dados, com o advento da interface gráfica e posterior WEB, os usuários queriam sistemas mais user-friends com janelinhas e botões, que forçaram a criação de monstrengos intermédios entre mainframe e baixa plataforma.

Chegando aos dias atuais com a computação em nuvem e terceirização completa dos serviços informáticos, com bons e maus resultados, somente o futuro ira dizer o quanto foi acertado, não esquecendo do altamente noticiado Bug do Milênio Y2k e suas soluções miraculosas.


A roupa nova do Rei.

Um antigo conto infantil onde um Rei gaboso e vaidoso é enganado por pilantras, que vendem roupas maravilhosamente lindas, que apenas pessoas inteligentes e fabulosas poderiam ver, por fim o Rei desfila nu nas ruas de seu reino.

Antes de migrar, comprar soluções faça uma análise profunda, elabore estudos de viabilidade econômica, calcule os custos envolvidos, cuidado com os custos ocultos e veja se vale migrar para novas soluções.


Entendendo um software Legado

Vou apresentar uma lista geral com inúmeros itens, que ajudam a tornar uma solução informática obsoleta, não é conclusiva ou completa, pois como o assunto é dinâmico surgiram novos e alguns podem até ser retirados.


Mobilidade

Atualmente vivemos a era First Mobile, todos os usuários e consequentemente querem que os aplicativos funcionem em mobile, independentemente de custos e riscos associados a entrar em novos canais. Muitas vezes empresas gastam tubos, empenham-se em adquirir soluções com preços elevados, mas que ao final acabam subutilizadas.

Os sistemas mais antigos estão limitados a tecnologia existente e muitas vezes novos canais implicam em novas soluções, que destroem performance e dificultam o fluxo de processamento original, obrigando soluções Franksteins para explorarem as tecnologias estreantes.


Escalabilidade

Ao pensarmos numa solução, a escalabilidade é um fator de extrema importância, afinal se o utilizador do Sistema, expandir seus negócios, aumentando a base de clientes, número de acesso e transações, o Sistema deve estar preparado a atendar a demanda, caso contrário tornar-se obsoleto rapidamente.


Obsolescência tecnológica

Um Sistema Informático é uma entidade viva, necessitando de um meio ambiente especifico para qual foi projetado, acontece que devido a rápida evolução tecnológica, muitas vezes o custo de equipamento alteram-se drasticamente, tornando o custo de manutenção de velhas maquinas elevados, incentivando a migração com a aquisição de novos equipamentos, obrigando a recompilaçao de códigos fontes e reinstalação de softwares, ocasionando obsolescência técnica, pois em algumas situações ocorrem conflitos com DLLs, Sistemas Operacionais e etc.

Em outras situações a própria linguagem de programação sofre alterações, que tornam velhos programas incompilaveis nas novas versões. Quando trabalhava no Banco Real, a IBM efetuou um release no S/370, que tornava o subprograma PSDATA, escrito em PL/1 e Assembler inoperante, o grande desafio e dor surgiu, devido a este programa ser utilizado em 100% das operações de cálculo de data. O Banco Real não aplicou o patch enquanto a IBM não liberou uma versão onde o PSDATA continuasse a funcionar sem erro.


Colaboradores

Mudanças tecnologias afetam o bem-estar da equipe, alterando o desempenho e quebra de produtividade, empresas com quadros de funcionários compostos por pessoas com mais senioridade, tem dificuldades em adotar novas tecnologias, o mesmo ocorre quando o mercado cria novos padrões que afetam os Sistemas Informáticos, a exemplo podemos citar o uso dos Telégrafos para envio de mensagens importantes em uso até meados dos anos 90, o Fac-símile que gradativamente o substituiu, por fim os e-mails, maquinas de escrever e editores de texto, pagers por celulares e etc. Todas estas mudanças implicou em substituir processos e procedimentos em uso durante décadas.

O mesmo se aplica aos terminais IBM 3270 e os pools de digitação para introduzir dados em sistemas. Com o processo obsoleto o Sistema informático que lhe dava surporte torna-se legado. Com certeza ainda existem empresas com microfilmes e processos para consulta-los e backups em fitas, cartridges e outros meios de outros tempos.


Suporte

Em algumas situações criticas, o fornecedor do software vai a falência, deixando inúmeros clientes sem suporte técnico e a linguagem deixa de ter evoluções ou deploys corretivos, deixando inúmeros utilizadores órfãos com um Sistema Informático moribundo, como exemplo relembramos o Clipper, o Dbase, o Macromedia Flash Player e tantos outros.


Incompatibilidade

Um problema que tira os cabelos da equipe de sustentação é a incompatibilidade de software com outros softwares, como todos estamos carecas de saber, os Sistemas Informáticos não são estanques e incomunicáveis, mas sim trocam informações com diversas entidades, em formato de arquivos mais variáveis e por todos os meios possíveis, estes pacotes necessitam estar pareado entre o remetente e o receptor, caso os softwares sofram alterações e está conversação se quebra.

Teremos um problema de incompatibilidade entre softwares, outro caso mais cabeludo é o caso quando se troca algum periférico do hardware e ocorre conflitos entre hardware e software deixando a equipe de desenvolvimento numa corrida contra o tempo, com muitas situações desastrosas pelo caminho.


EOL – End of Life

Este é o pior cenário possível num sistema Legado, ocorre quando o Software encontra o seu fim, em decorrência de obsolescência de software ou hardware, num cenário assim nada poderá ser feito, a não ser migrar, de preferência num processo planejado e com tempo hábil para testes e acompanhamentos.

Um momento muito triste para o desenvolvedor que trabalhou durante anos, quiçá décadas no projeto e ao final vê-lo desaparecer para sempre, sendo apagado e retirado do DataCenter. Dói muito pensar nisso.


Custo de Manutenção

O terror do gestor de infraestrutura e desenvolvimento, ao aumentar o custo da manutenção devido à complexidade crescente do software, problemas de escalabilidade que implicam a aquisição de mais hardware e mesmo o consumo elevado de insumos para a operação diária do Sistema, situações que rapidamente tornam o Software inviável economicamente e forte candidato a EOL.


Custo de Treinamento

Um grande problema que tende a piorar em nossa geração, o custo elevado para treinar técnicos e operadores em tecnologias arcaicas sem GUI, sem multiplataforma e aparência sisuda e espartana.

A cada dia surgem novas tecnologias e metodologias de desenvolvimento, que atrai as novas gerações de DEVs catequizando e criando clubinhos, que os dificultam trabalhar com softwares legados e com a necessidade constante de criar, fazem uma pressão para o novo e abandono do legado.

Por isso uma tecnologia com poucos desenvolvedores e estudantes desta tecnologia, torna-se um candidato perfeito a EOL, por isso antes de adquirir uma ferramenta para sua empresa, verifique as tendências do mercado.

O SAP é um exemplo perfeito, conquistou o mercado nos anos 90 e hoje luta para sobreviver ao meio de tantas mudanças, existem outros erps que sofreram do mesmo mal, alto custo de formação e baixo retorno salarial, que acabou espantando os programadores.


Refatoração

No ciclo de vida de um software é o equivalente a visitar o cirurgião plástico, toques do Dr. Pitanguy, em linhas gerais é analisar um software antigo, mantendo todas as suas funcionalidades e workflows, sob uma roupagem nova e mais performática. Uma maquiagem que estende a vida útil de um Sistema, em alguns casos durante mais de uma década. Eu participei num projeto do gênero, na Zurich italiana participei de um equipe que refatorou o Sistema de IBM Mainframe para AIX Unix.


Lentidão

É um péssimo sinal, tanta coisa pode estar envolvida, os suspeitos são muitos, desde cabos de redes, servidores, provedores de internet, hardware com anomalia e o pior de todos: SOFTWARE mal projetado, todo sistema informático é uma maravilha, no ambiente de teste, com pouca intervenção funciona que é uma maravilha, bastou passar a produção, que os problemas surgem.

Sejam problemas na base de dados, seja índices mal feitos, conflitos entre aplicações, gargalos em workflow e usuários imaginativos. E quanto mais usado, mais deteriorado fica, chegando a pontos cruciais, onde Lideres de Projeto avaliam refatoraçao, remodelação, migração e em casos graves EOL.


Multiplataformas

Nos anos 90 a expressão usada eram Canais: canal web, canal emulador, canal móvel, cana pc e etc. Atualmente o mobile é o rei, como dizem First Mobile, caso o sistema não tenha sua versão em APP em alguma lojinha da moda, Android APPs, Microsoft Apps e ou na mais exclusiva e cheia de nove horas IOS Apps.

É uma sentença de morte, o Sistema Informático que não foi previsto em operar em  Multiplataforma está com seus dias contatos, rapidamente chegar uma empresa de consultoria com uma solução baratinha para ser implementada e aí temos novamente EOL.


Incompatibilidade

Este problema é um pouco mais raro, porem acontece com as melhores famílias, imagine um Sistema Informático que utiliza um periférico especifico para a introdução de dados, por exemplo o PDA Palmtop, era o queridinho no princípio da década de 2000, a Datarroba que o diga, quando a empresa deixou o suporte dos equipamentos, os softwares que o utilizavam ficaram incompatíveis com o novo sistema Android e com isso EOL.


Não atualização

Um risco que surge em utilizar softwares Open-Source, a moda do momento, dominando corações e agregando equipes pelo mundo afora, porém como não tem um suporte oficial garantido com Garantias Legais, inesperadamente aquele software que suporta seus negócios deixa de ser atualizado, e as contas para manter o projeto vivo é absurda, logo, a solução para softwares sem atualização é EOL.


Flexibilidade

Um problema em softwares antigos e construídos sobre outros paradigmas e sua falta de flexibilidade a mudanças, principalmente devido a equipe de sustentação do software, o que gera grande problemas quando surge a necessidade de alteração estrutural, a resistência das pessoas em modificar, torna-se o software um sério candidato a EOL.


Novas funcionalidades

Como sempre digo, perdoem a repetição, mas Sistemas Informáticos são entidades vivas, precisam-se adaptar-se, modificarem-se, evoluírem e apenas os mais aptos sobrevivem. Um programa que não esta apto a receber novas funcionalidades com certeza será substituindo por um programa da concorrência.

Se a empresa for incapaz de agregar novas funcionalidades a seu parque tecnológico, com certeza morrera, lembro-me sempre do Clipper que tinha limitação ao uso de memória baixa, um programa crashava e não compilava se ultrapassasse os 640 kilobytes de memória.


Falhas de Segurança

Um gestor de projetos não deve dormir no ponto, estar atento ao que acontece no submundo da informática, vendo a DeepWeb, os newsletters de segurança, atualizando softwares de apoio e mantendo backups a postos.

Nunca sabemos quando seremos atacados por hackers e outros vigaristas virtuais, por isso nosso parque informático necessita estar seguro, um sistema informático com falhas de segurança deve ser remendado e caso os custos sejam proibitivos, sabem a máxima, EOL nele.


Custos Operacionais

Em alguns momentos o Software está redondo, atende a todas as necessidades, usuários e desenvolvedores estão felizes, mas nem tudo é céu azul, nuvens de tempestade surgem no horizonte.

Qual o problema? Custos operacionais elevados, por alguma razão a ser analisada, os custos de operação são elevados, sejam na aquisição de insumos, seja nos equipamentos que necessitam de ajustes ou até mesmo no consumo de eletricidade ou até mesmo os custos de manutenção que conduzem o Sistema para o EOL.


Manutenção Cara

Este é o grande problema dos softwares legado do ambiente IBM Mainframe, o aluguel da máquina é elevado, os custos são calculados em MIBS, a mão de obra é rara, com custos elevadíssimos em Hora/Homem e as novas gerações não curtem a tela verde dos emuladores 3270. Forçando as grandes empresas migrarem seu parque informático para a Cloud Computer, empresas como Microsoft, Google e Amazon estão na liderança destes Data Centers modernos, que na minha modesta opinião não são tão diferentes dos antigos CPDs da IBM.


Um longo caminho

Agradeço sua atenção até este ponto, foi um longo artigo, tantas definições, ideias para apresentar o que é um Software Legado, saiba que o seu fabuloso projeto de hoje , construído no Estado da Arte da Tecnologia contemporânea um dia será o Software Legado, maltratado e vilipendiado e alguns casos até odiado.


Conclusão

Jovem padawan, quanto mais mergulhar no Mundo das Tecnologias, mais contato com Software Legado encontraras, o cemitério das tecnologias ultrapassadas é imenso, o memorial das Linguagens de Programação esquecidas e largadas renderia um artigo com milhares de páginas.

O meu objetivo nestas palavras foi apresentar alguns elementos que tornam o Software obsoleto e implica em sua eliminação. Lembrando que muitas vezes as funcionalidades são reescritas em novas linguagens, velhos bancos de dados migram em formato semelhante ao anterior. Então em tese não desaparecem apenas se transformam.

Esteja atento as tendências e surf a onda, mas cuidado para não se tornar um especialista em tecnologia ultrapassada, pois no primeiro momento seus rendimentos serão elevados, mas no futuro não encontrara projetos para aplica-los.


Espero ter ajudado ate o próximo artigo.


Referência Bibliográfica


WIKIPEDIA - A Enciclopédia Livre, faça parte, ajude atualizando ou criando verbetes http://www.wikipedia.org


Google Books um repositório com milhões de livros digitalizados https://books.google.com/


Internet Archive, tudo aquilo que um dia foi publicado veio parar aqui. https://archive.org/


Biblioteca de ícones https://www.flaticon.com/


Article content


Article content

Mais momento jabá, um passeio noturno pela bela cidade de Guararema/SP as margens do Rio Paraíba do Sul, com a majestosa Maria Fumaça e seus passeios de Trem a Vapor nos antigos trilhos da Ferrovia Central do Brasil, uma pacata urbe com suas tipicas casas do Brasil de antigamente , visite meu vídeo e veja para onde fui desta vez :


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


Bom curso a todos.

Article content

https://www.linkedin.com/in/VagnerBellacosa

Article content

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?


Article content

https://www.youtube.com/user/vagnerbellacosa