Você sabe o que são bits bytes kilobytes?

Bellacosa Mainframe apresenta Bits e Bytes

Você sabe o que são bits bytes kilobytes?

Bellacosa Mainframe

4,349 followers

July 5, 2025

Uma lógica diversa: BITs & Bytes:

As vezes estamos em meio a uma aula chata e cochilamos, perdendo alguns conceitos que podem fazer falta no dia a dia do trabalho, sob esta ótica vamos falar sobre o conceito fundamental do processamento de dados.

A base numérica em2, nos primatas de polegares opositores e com 10 dedos criamos um sistema numérico em base 10, e com isso resolvemos os principais problemas necessários ao nosso cotidiano, mas a informática veio complicar tudo.

Os computadores por sua essência elétrica trabalham em apenas dois estados: LIGADO e DESLIGADO, com isso surgiu a necessidade de adoptar todo um sistema numérico novo, o sistema binário. Computando informações em múltiplos de2, com essa necessidade surgiu uma nova padronização chamada BIT, um anagrama de (BInary digiT).

Em diversos trabalhos estes conceitos básicos são muito uteis auxiliando o desenvolvedor de código e seu domínio protege e ajuda a evitar alguns erros básicos e primários.

Lembre-se um BIT solitário nada pode fazer, por isso criamos um conjunto de bits, que por convenção e devido a facilidade de operação, utilizamos um conjunto de 8 bits, denominado de BYTE.

O byte é a menor unidade de estrutura conhecida, sendo o bloquinho Lego universal da computação, tudo é construído a partir dele e suas combinações, lembre-se ( 2 elevado a 8) = 256, que é o tamanho da tabua de caracteres dos sistemas de codificação computacional.

A partir do byte foram sendo criadas novas denominações para o agrupamento de bytes, a seguir apresento a tabela de espaço, nome e representação matemática.

Bits & Bytes

Nome ==> Espaço ==> Formula==>

Bit ==> 0 ou 1 bit ==> 2⁰ ==> 1 bit

Byte ==> 00000000 até 11111111 bits ==> 2⁸ ==> 8 bits

Kilobytes ==> 1024 kb ==> 2¹⁰ ==> 1024 bytes

Megabyte ==> 1024 Mb ==> 2²⁰ ==>1.048.576 bytes

Gigabyte ==> 1024 Gb ==> 2³⁰ ==>

1.073.741.824 bytes

Terabyte ==> 1024 Tb ==> 2⁴⁰ ==>

1.099.511.627.776 bytes

Petabyte ==> 1024 Pb ==> 2⁵⁰ ==>

1.125.899.906.842.624 bytes

A título de curiosidade os próximos limites são: Exabyte, Zettabyte e Yottabyte, mas espero que você não tenha que usar :P

Então quando forem codificar lembre-se destas convenções, pois mesmo programadores experientes comentem deslizes e acabam se confundindo com os armazenamentos e nas documentações técnicas, em alguns casos esse tipo de erro levam a constrangimentos e falhas na alocação de espaço em produção elevando custos do projeto.

Entenderam onde quero chegar? Quando produzimos documentos técnicos, devemos informar o quanto de tráfego iremos gerar na rede, quanto espaço iremos necessitar armazenar na nuvem ou em servidor, uso de CPU e buffer de memória, capacidade de processamento e sua velocidade, entre outras coisas.

Espero ter ajudado e qualquer coisa deixe comentário. 

Bellacosa Mainframe apresenta o dilema da seringa em problemas no processamento de dados e analise de sistemas

 

Dilema da Seringa em programação de sistemas

Bellacosa Mainframe

4,349 followers

July 5, 2025

O Dilema da Seringa

Em análise de sistemas somos constantemente colocados perante este dilema, mas afinal o que é ou que significa o DILEMA DA SERINGA?

Em poucas palavras, este dilema resume-se ao analista programador deixar o problema explodir em seu colo, por inocência ou inexperiência na execução da sua atividade cotidiana, mas espera aí? O que eu fiz de errado? Será a pergunta do jovem padawan e mesmo de alguns jedis.

Ao desenvolvermos códigos sob especificações, muitas vezes o documento vem com lacunas, que um programador macaco velho, irá notificar o Business Analyst ou a área usuária para maiores esclarecimentos e sanar todas as dúvidas antes de programar.

Mas às vezes por falta de tempo, ou demora do usuário em responder, o programador inicia seu labor, assumindo algumas suposições, cuidado isso pode dar ruim. Para evitar isso, salvaguarde-se sempre documentando mediante e-mails, suas ações e decisões, NUNCA assuma nada, coloque-se em seu lugar, às vezes não temos visão do todo, codifique baseado nas especificações, não invente, não complique e não saia fazendo arte.

O dilema da Seringa é isso mesmo: A AGULHA DA SERINGA DEVE ESTAR SEMPRE APONTADA PARA A BUNDA ALHEIA, NUNCA PARA A SUA. Por isso documente, não aceite esclarecimentos telefônicos, ordens de subalternos, ou terceiros extra equipe, fuja de especificação em rascunhos de papel de pão e/ou post-it.

Todo desenvolvimento deve estar documentado na especificação, validado e autorizado por meio de e-mail e anexado copias na pasta de documento do projeto. Atualize todos os documentos e informe todos os participantes sempre que receber novas especificações.

Lembre-se um simples IF pode causar mais danos que sua vã filosofia supõe. Cuidado e olho vivo!

Todos são amigos, mas quando a bomba explode, ela sempre estoura no lado mais fraco. Salvaguarde-se e avance somente quando as dúvidas estiverem sanadas, não tenha vergonha, pergunte até estar tudo esclarecido.

Muitos acreditam que Informática é uma ciência da área de Exatas, porem ela pertence a humanas, ficando na fronteira entre as duas áreas, por mesclar conhecimento de áreas comportamentais, negócios, tecnológicos e legais, use a arte de conversar, refinar, analisar, pensar, rascunhar e reiniciar o ciclo em que cada alteração.

Concluindo seu trabalho diário, nunca deixa a agulha da seringa apontada para seu bumbum, salvaguarde-se e nunca assuma ou tome decisões sem autorização superior.

Espero ter ajudado.

https://www.linkedin.com/pulse/dilema-da-seringa-em-programa%C3%A7%C3%A3o-de-sistemas-bellacosa-mainframe-btvaf/

Leia o artigo completo no LinkedIn

Deu ruim no levantamento de Requisitos: A Síndrome de Dr. Ivon SaF.

 

Análise de requisitos, sistemas legados e IBM Mainframe

O trabalho inicial para um projeto de software garante o sucesso ou fracasso da equipe, atualmente temos inúmeras metodologias para o desenvolvimento de código, é independente da tecnologia utilizada, existe um ponto que costuma dar bem ruim, um atalho rápido e direto para o infortúnio.

Neste artigo irei comentar sobre um problema muito comum no levantamento de requisitos, que geram lacunas e má coleta de dados. Segundo a lenda, um médico alemão, na idade média, perdia muitos pacientes devido a ter pressa em curá-los, apressando-se no diagnóstico, sem ao menos compreender realmente quais os sintomas da doença, contando com a sorte e acaso nas suas poucas curas.

Em informática a síndrome do Dr. Ivon Saf, se multiplicou rapidamente e expandiu-se para diversos ambientes de desenvolvimento. Atrapalhando e elevando os custos de codificação, estourando orçamentos e prazos, enlouquecendo programadores e arruinando reputações. Este conceito foi-me apresentada pelo grande mestre Jedi Marcio Martini.

Um consultor de Análise de Sistemas com muitas técnicas e ferramentas aprendida s com o próprio Mestre Yoda dos Mainframes , Martini que atuou durante décadas, treinando gerações de analistas nos anos de 80 e 90 do século passado e Y2k ajudando a combater essa síndrome e a gerarmos bons códigos para a Alta Plataforma.

Conheça mais detalhes da SINDROME do Dr. IVON SAF, ou síndrome da Incrível VONtade de SAir Fazendo, levando inúmeros projetos rumo ao fracasso, que graças a inexperiência, inocência e necessidade de colocar-se em evidência.

O analista de sistemas e sua equipe de desenvolvimento fazem um mal trabalho, gerando erros de entendimento, erros de programação e nos casos mais graves, enviando a produção software incompatível com as necessidades do cliente, causando danos de imagem e custos ao cliente pelo uso ineficaz de ferramenta.

Afinal, em detalhes, o que é esta síndrome, resumidamente, é a sanha, a vontade de sair codificando, sem antes fazer uma boa análise e reflexão sobre o problema, para uma boa codificação, recomenda-se que use o maior computador de todos os tempos: com seus periféricos poderosos: Lápis, Papel e Borracha, juntamente com um processador multitarefas bem potentes: o seu cérebro.

Entre em ação, rascunhe, desenhe, faça teste de mesa, entenda a necessidade, verifique a problemática sob várias óticas, a continuação irei apresentar algumas técnicas utilizadas em Mainframe, aprendida no antigo Banco Real e utilizada durante décadas nos diversos Bancos em seu ambiente de Alta Plataforma por gerações de programadores.

Independente da sua posição, Junior, Pleno ou Sênior somos todos analistas. Devendo obter informações bem detalhadas sobre o software a ser desenvolvido, sejam ela desenhos técnicos legados, fluxogramas, software descontinuado, entrevista com analista de sistemas e a mais importante entrevista com o cliente para sanar dúvidas e entender o que se deseja ser feito.

Lembre-se que ao desenvolver um software devemos sempre atender a 3 tipos de requisitos: requisitos funcionais, requisitos não funcionais e regras de negócio. Lembrando em linhas gerais que Funcionais são aqueles requisitos que tratam da função; Não Funcionais referem-se as questões de ambiente, performance, espaço em disco, infraestrutura de modo gerais e finalizando Regras de Negócios, por exemplo, legislação, regras de formatação, workflow e especificidades do produto.

Existem inúmeras técnicas para o Levantamento, a seguir deixo algumas não exaustivas, reduzidamente apenas para nos situar sobre o trabalho:

1) Entrevista técnica: o analista irá reunir-se com os programadores que conhecem bem o software para entender seu funcionamento, input, outputs, dependências o e o ambiente;

2) Entrevista Funcional: o analista se reúne com a área-cliente e outros players, conhece a realidade e as necessidades do utilizador;

3) Questionário: após a primeira e segunda bateria de entrevistas, ocorre um refinamento das necessidades e com as dúvidas surgidas se faz um questionário com as principais dúvidas e questões;

4) JAD -Joint Application Design: é um projeto de interação continua, onde todas as equipes envolvidas se reúnem para discutir, num circuito de retroalimentação para refinar as necessidades e as suas possíveis soluções.

5) Prototipação: após as inúmeras reuniões, refino, levantamento, desenho técnico, desenho funcional e desenho arquitetural; a equipe produz um protótipo para ser validado com o utilizador antes de iniciar a codificação a sério.

Concluindo.

Em conclusão, a síndrome do Dr. Ivon Saf, prejudica muito o trabalho da equipe de sistemas, pois ao sair codificando, desenhando, modelando afobadamente, sem conhecer a real dimensão do problema, a necessidade do cliente, as limitações técnicas e custos ocultos. O produto final entregue estará com inúmeras anomalias e erros estruturais que poderão comprometer a competitividade da empresa, a imagem da equipe e causar sérios problemas ao usuário.

Então antes de sair fazendo, contenha-se, respire, pense, reúna-se e converse. Crie um documento técnico, valide os principais pontos, sane todas as dúvidas, veja se a solução se adequa a realidade do cliente, veja se os equipamentos suportam a solução.

Cuidado com a pressa de entregar. Não gere retrabalhos desnecessários, que gerem o aumento do custo do projeto exponencialmente. Lembre-se o lápis e o papel são baratos e permitem inúmeras revisões.

Espero ter ajudado, aproveito para perguntar se conhece alguém que sofre ou sofreu desta síndrome? Escreva nos contando o que aconteceu, as implicações e as soluções. Caso tenham interesse poderei num próximo artigo explanar um pouco mais sobre JAD, Levantamentos e procedimentos para análise em Mainframe. Fiquem bem, estudem, evoluem, compartilhem, unidos somos mais fortes.

#AnaliseSistemas #Legado #IvonSaf #Requisitos #Programaçao #codificaçao

Momentos nostálgicos de uma epopeia, a Vagneida rumo a Portugal, que durante 11 anos, vivi uma experiência única em terras lusitanas, um momento cheio de memorias, coisas fabulosas e lendárias, visitando cidades milenares com um povo acolhedor e cortes, com uma culinária dos deus e muita mas muita historia. Um video para distrair na jornada https://www.youtube.com/watch?v=skgfjJG5x3s

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

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

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

#AnaliseSistemas #Legado #IvonSaf #Requisitos #Programaçao #codificaçao

https://www.linkedin.com/pulse/deu-ruim-levantamento-de-requisitos-s%C3%ADndrome-dr-ivon-4hfxf/

🔥 Leia no LinkedIn Ler no LinkedIn