Balanced Line pattern

Oi pessoal,

O blog andou meio paradão, recebi algumas cobranças e estou voltando com mais um post, desta vez falando sobre uma espécie de “design pattern” das antigas chamado “Balanced Line”.

Na era onde os mainframes dominavam (era Jurássica) não era tão simples fazer uma atualização de cadastro on-line. A coisa acontecia em “batch”, ou seja em lotes.

É complicado explicar isso para o pessoal mais jovem, mas vou tentar:

Disco rigido nessa época era artigo de alto luxo (caríssimo) e, por causa disso, os cadastros (clientes por exemplo) eram guardados em rolos de fita magnética. O movimento de inclusão, alteração e exclusão era perfurado em cartões, e havia um processo “batch” através do qual esse cadastro era atualizado.

Lia-se um registro de cartão perfurado e dependendo do tipo (Inclusão, Alteração, ou Exclusão) ia-se gerando o novo cadastro em fita magnetica com os novos registros incluidos, alterados e excluídos.  Esse processo era tão comum que virou um design pattern chamado “Balanced Line”.

Fluxograma do processo:

Qualquer programador daquela época deve ter feito isso algumas centenas de vezes.

Tenho um colega em Natal – RN (Cíco) que certa vez me contou que se preparou para fazer um teste em uma empresa, e o candidato que fez a prova antes dele lhe disse que a prova era fácil, só um “Balnced line “zinho”. O problema é que o Ciço não sabia que o nome do processo que ele estava careca de fazer tinha esse nome. Ele disse: Vixe, me lasquei, não tenho nem idéia do que se trata e desistiu de fazer a prova. Quando descobriu o que era, ficou doido.

Um conselho pra garotada: Aprendam “Design Patterns”.

Até a próxima.

Debugando com o Xinês

Ola pessoal,

Depois da epopéia da compilação vinha a parte mais complicada. Era hora de testar o seu programa, ver se tudo estava funcionando como pensado e codificado (perfurado).

IBM/360

Só para matar a sua curiosidade, esse era um IBM/360 (imponente). Dava até medo. É bom lembrar que uma máquina dessas custava milhões (eu disse milhões) de dólares, e não é preciso dizer que alunos não chegavam nem perto dela. Esse pessoal que você vê na foto eram os “Operadores do computador”.

Voltando ao que interessa, precisávamos preparar uma massa de dados de teste, claro, perfurando mais alguns cartões. Acrescentava-se alguns cartões de JCL (Job Control Language) antes dos dados de teste e o seu programa estava pronto para ser testado.

Entregávamos por uma janelinha o nosso programa (lembre-se que era físico: um monte de cartões perfurados amarrados com um elástico) ao operador. Esse cara era responsável por colocar o seu programa na leitora de cartões e depois executá-lo nessa super máquina. O resultado era uma listagem.

Agora não havia erros de sintaxe e sim erros de execução (runtime). Quando voce via algo como “Divide by Zero” era até fácil de identificar o problema. O complicado era quando o resultado não era o esperado, ou o programa foi “abortado” por que estourou o tempo de execução configurado para alunos. Isso era um indicativo de que seu programa estava em “loop”.

Era chegada a hora de “debugar”. Como voce deve ter percebido, não havia teclas de atalho para tal tarefa. Voce precisava do auxilio do “Xinês”.

O “Xinês” nada mais era que uma folha de papel em branco onde voce escrevia o nome das variáveis com as quais o seu programa interagia e registrava os valores por elas assumidos.

O Debugador era você. Isso mesmo, você fazia o papel do processador do computador, e linha a linha do seu programa (seguindo a listagem com uma regua) ia atribuindo valores a essas variáveis e registrando no “Xinês”.

Que beleza hein?

E voces reclamam de debugar nos dias de hoje.

Debugar era ruim desde aqueles tempos, uma dica: use TDD.

Para quem não conhece o acrônimo, TDD siginifica (Test Driven Development) – Desenvolvimento orientado por testes.

Grande abraço e até a próxima aventura.

A epopéia da compilação

Oba moçada, tudo beleza?

Ah como era legal compilar…

Depois de digitar (perfurar) cada linha de código em cartões voce tinha o seu programa, era algo físico, voce podia tocá-lo, acariciá-lo, mas o mais prudente era mesmo amarrá-lo com uns dois ou tres elásticos resistentes, porque dalí ele ia para a próxima etapa da nossa epopéia, a compilação.

Depois de adicionar alguns cartões de controle como sendo os primeiros do deck utilizando JCL (Job Control Language), você estava pronto para entregar o seu filho (ou melhor, o seu programa) para uns camaradas que eram chamados de operadores de computador.

Por uma janelinha voce entregava a sua cria (programa) e eles, os operadores, empilhavam-no numa máquina chamada leitora de cartões. Só dá pra explicar com foto.

Depois de lido, interpretado e executado no computador (agora é mainframe), voce recebia o resultado numa listagem com os erros de sintaxe. Não sei se deu para perceber que cada erro de sintaxe era um cartão perfurado no lixo. O planeta agradece o avanço dessa tecnologia.

Pois é pessoal, era necessário substituir um por um, os cartões com erro, e passar pelo processo todo novamente, até que depois de várias tentativas a listagem apresentava a mensagem: 0 erros.

Ufa, o seu programa estava, enfim, compilado.

Próxima etapa: Rodar o programa para ver se estava fazendo mesmo o que voce imaginava, mas isso fica para um próximo post.

Me ferrei, meu programa caiu no chão.

Como assim, o seu programa caiu no chão?

É isso mesmo que voce acabou de ouvir. Quando me matriculei no curso de programação de computadores da PUC-RJ em 1980, recebi uma caixa com 3.000 cartões destes:

Depois de aprender um pouco de Fortran, fomos até o RDC (Rio Data Centro) onde nos apresentaram as perfuradoras de cartões:



Cada linha de programa era um cartão perfurado nessa incrível máquina que fazia um barulho danado. Imagina uma sala com 10 perfuradoras. Que beleza!

Os alunos se revezavam nessas máquinas perfurando (codificando) seus programas que transformavam-se em um deck de cartões amarrados com um elástico (liga, para o pessoal aqui do Nordeste).

De vez em quando o elástico se partia e o seu programa com 457 cartões caia no chão e voce estava literalmente ferrado. Imagina aí embaralhar as linhas do seu código.

Quando voce estiver em sua estação de trabalho ou notebook numa IDE toda poderosa, lembre-se desses alunos que podiam perder todo o seu trabalho por causa de um esbarrão ou elástico (liga) velho.

No proximo post eu conto como era o processo de compilação…

Até lá.

O Jr é o mais sênior do Grupo

Olá pessoal,

Este é o meu primeiro blog, acredite quem quiser. Nunca gostei muito de escrever, talvez esse seja o maior motivo (ou desculpa) para não “blogar”, mas tenho aprendido tanto através de blogs de excelentes profissionais de TI que me senti no dever de dar a minha contribuição.

O título desse blog : “O Jr é o mais sênior do grupo” surgiu numa “Thread” do grupo .Net Architects. Talvez o Jr (eu) seja o membro mais velho a participar desse excelente grupo de discussão sobre Arquitetura de Software, mas nem de longe o mais sênior.

Esse, por acaso, é o meu diploma do curso de “programação de computadores” emitido pela PUC-RJ em junho/1981.

Muitos do grupo ainda nem eram nascidos quando terminei esse curso, e por isso, acredito ter algumas boas estórias pra contar.

Esse blog, será o local onde contarei, caso haja interesse de vocês, um pouco da minha experiência como “programador”.

Alguém já codificou em algo parecido com isto:

Pois é, isso é só o começo…