26 anos de Delphi

Dia 14 de fevereiro de 2021, o Delphi completou 26 anos! Ainda me lembro quando comprei o Delphi 1, na falecida Fenasoft, por R$ 50 (um preço excelente, diga-se de passagem). Guardo ele até hoje, com muito carinho, inclusive os manuais, etc.

Vinha de um histórico que, no IBM-PC, passou por Turbo Pascal, ASM, dBase/Clipper, isso tudo em ambiente DOS. Quando o Windows começou sua ascensão com o lançamento da versão 3, procurei algumas linguagens de programação para aquele ambiente, mas não me adaptei à nenhuma delas! Nem mesmo ao Turbo Pascal para Windows! Era tudo muito “cru”, chamadas de API com nomes gigantescos que dificilmente conseguiria memorizar, pouca praticidade, tudo muito manual, etc.

Foi então que em 1.995 o Delphi foi lançado, e com isso finalmente comecei a me aventurar em programação para Windows, sem precisar me martirizar com chamadas explícitas à APIs com nomes estapafúrdios, nem tentando imaginar como ficaria uma tela em runtime e, para a minha felicidade, usando uma linguagem que eu adorava: Pascal. Além disso, já trazia acesso à diversos bancos de dados através da BDE! Tudo bem, a BDE depois se provou como algo problemático e deficiente, mas para a época, parecia uma maravilha!

A VCL possibilitava construir aplicações com uma interface rica, de forma rápida e intuitiva! Houve um “boom” de componentes de terceiros, alguns uso até hoje, como Infopower, IBObjects e ReportBuilder (na época conhecido como piparti). Havia também uma infinidade de livros de Delphi, tanto no mercado internacional como no nacional. Foi realmente uma época de ouro!

Algumas versões ficaram eternizadas como o suprassumo do Delphi, e ainda são usadas por muitos desenvolvedores, como o Delphi 5 e o 7.

De lá pra cá, muita coisa aconteceu com ele: da Borland passou para a Inprise que passou para a CodeGear que passou para a Embarcadero (será que esqueci de alguma?). O Delphi sofreu bastante com essas mudanças. Algumas versões deixaram muito a desejar, principalmente em termos de qualidade/estabilidade da IDE. O Help integrado, que era excelente, foi “esquecido” por algum tempo e até hoje sofre os efeitos disso. Algumas apostas se mostraram furadas, a ponto de serem desprezadas algum tempo depois (Delphi for .NET, Delphi for PHP, Kylix, etc). Uma falta de política focada em universidades também contribuiu para que o Delphi perdesse espaço no meio educacional. Muita gente falando que o Delphi tinha morrido (alguns ainda falam ou acreditam nisso), mas estão muito enganados! Felizmente isso vem mudando nos últimos anos, e o Delphi nunca foi tão ativamente desenvolvido como agora.

O fato é que, 26 anos depois, o Delphi continua sendo minha ferramenta de programação preferida. Ele me possibilitou criar todos os tipos de aplicações que precisei desenvolver até hoje! Se integra com tudo e permite desenvolver qualquer tipo de projeto, desde jogos até aplicações comerciais, sites, webservices e – mais recentemente – aplicações mobile (iOS/Android), bem como para Linux ou MacOS, mantendo todo o poder do RAD (Rapid Application Development). Em termos de produtividade, creio que não tenha concorrente que ofereça o mesmo potencial! Quem trabalha sozinho e precisa dar conta de tudo: análise, desenvolvimento, suporte, etc. dificilmente daria conta do recado sem ter algo como o Delphi ao seu lado!

Enfim, fica o meu agradecimento à todos aqueles que possibilitaram o surgimento de algo tão revolucionário como foi o Delphi, e aos que até hoje trabalham pelo seu sucesso, incluindo os desenvolvedores que, como eu, sempre acreditaram na ferramenta.

Parabéns Delphi, muitos anos de vida!

PS: Durante muitos anos fui presidente do DUG-BR (Delphi Users Group Brazil). Naquela época, organizávamos eventos sobre Delphi, que chamamos de DDD (Delphi Developers Day). Foi um tempo muito bom, de muito aprendizado, onde conhecemos muita gente nas diversas cidades onde fizemos os DDDs, mas isso é uma outra história, para um outro post 😉

Share and Enjoy !

A Demoscene

Assembly 2009

Demoscene é uma subcultura da arte computacional especializada na produção de demos, apresentações áudio-visuais não-interativas, que são executadas em tempo-real em um computador.

Wikipedia

A definição acima descreve bem resumidamente o que era a Demoscene, mas minha intenção nesse post é falar sobre como a conheci, além de lembrar um pouco do contexto da época e do porque considerar as demos algo especial que merece ser lembrado.

Contexto

No final da década de 1980, início da década de 1990, o poder computacional dos microcomputadores era muito, mas muuuuito mais limitado do que qualquer smartphone atual! No Brasil, o mercado de microcomputadores era basicamente composto por clones do Apple II (fabricados pela CCE, Dismac, Microdigital, etc) e por IBM/PC’s (fabricados pela Prológica, Itautec, etc), além de algumas outras marcas/plataformas menos importantes (fãs dos MSX vão querer me matar). Os Apple II (obrigado Steve Wozniak), eram basicamente usados em cursos introdutórios de informática, onde se aprendia os conceitos básicos de programação utilizando o próprio Basic nativo. Os cursos mais “avançados” usavam os PCs (XT, AT, 286, 386) para ensinar dBase/Clipper, Supervisicalc (o avô do Excel), Wordstar (avô do Word), etc.

Quem tinha um pouco mais de dinheiro podia se dar ao luxo de fugir desses PCs nacionais “meia-boca” e montar seus próprios PCs, geralmente com peças trazidas do Paraguai pelos “muambeiros”. Era comum os chamados “foguetões”, ônibus fretados que saíam em direção à Ciudad del Este numa sexta-feira, percorrendo milhares de km, chegavam lá no sábado de manhã, deixavam o pessoal fazendo compras para voltar logo em seguida. Trazia-se de tudo! Desde alho, roupas, brinquedos, até impressoras, monitores (de tubo), placas mães, cpus, gabinetes, placas de video, memórias, etc. Isso porque a reserva de mercado tornava praticamente impossível importar computadores fabricados no exterior (tudo para fomentar a indústria nacional… nem preciso dizer que não deu certo)!

Solution 16
Solution 16, da Prológica

Um PC “top” da época seria um 386DX de 40Mhz, com 4MB de RAM, placa SuperVGA, monitor Samsung Syncmaster 3 ou 4, modem USRobotics, etc. Percebeu que até agora não usei a palavra GIGA pra nada?! Pois é! Processadores de 40 MEGAHertz, 4 MEGAbytes de RAM, etc… inacreditável, não?!

A internet era para poucos! Na verdade, a maioria das pessoas nem sabia que ela existia. Basicamente, no Brasil, a internet só existia em algumas universidades públicas. Ainda assim, a World Wide Web (WWW, ou simplesmente Web) era uma recém-nascida e desconhecida por nós. Usar a internet significava basicamente usar programas específicos para executar funções específicas: ftp para troca de arquivos, nntp para grupos de discussão, IRC para chat ao vivo, Telnet para conectar computadores remotos, etc. Com a popularização da Web, ela acabou se tornando quase que um sinônimo para a internet (obrigado Mosaic e Netscape).

Nessa época, comecei um estágio na ESALQ/USP, onde tive o primeiro contato com a rede mundial de computadores. Eu já era SysOp da WarmBoot BBS, e acessar a internet abriu um mundo novo de possibilidades para obtenção de arquivos para disponibilizar aos usuários do BBS. Até então, os acervos de arquivos dos BBS eram baseados em CDs de shareware ou no envio de arquivos pelos próprios usuários. Com a internet, mais especificamente com o FTP e sites como o Simtel 20, ficava muito mais fácil e rápido ter acesso à programas e novidades das mais variadas! Foi numa dessas “zapeadas” pelos FTPs da vida que vi um diretório de arquivos chamado “demos“. Baixei alguns pra ver do que se tratava, e foi aí que meu interesse pela Demoscene nasceu.

Demos?

As demos eram programas, geralmente codificados em linguagem C e/ou assembly (linguagem de máquina), onde o objetivo era criar animações gráficas explorando ao máximo os recursos (limitados) dos hardwares disponíveis, gerando objetos em 3D, chamas, sombreados, etc.

Uma boa demo era aquela que conseguia reunir as seguintes características:

  • Maior suavidade nos movimentos
  • Boa resolução
  • Trilha sonora original (geralmente arquivos MOD nas Demos, e MIDI nas Intros)
  • Efeitos gráficos
  • Muito “3D”
  • O menor tamanho de executável possível

Hoje em dia é normal assistirmos filmes repletos de efeitos especiais e cenários que só existem digitalmente. Essas cenas são todas renderizadas (desenhadas) por softwares executados em computadores “fodásticos”, que no final geram uma sequência de imagens que vão compor as cenas do filme. Esse processo pode levar horas, dias, semanas ou meses, dependendo da complexidade dos objetos na cena, duração, resolução e nível de detalhamento desejado, etc.

O fantástico das demos era que praticamente tudo que você estava assistindo estava sendo calculado e desenhado em tempo real, usando hardwares extremamente variados e limitados! Diferente de um filme que já tem todas as cenas produzidas anteriormente, as demos calculam e geram as animações na hora!

Geralmente eram produzidas por várias pessoas, entre programadores (coders), artistas gráficos, compositores, etc. Algumas se juntavam e criavam um DemoGroup, como, por exemplo, Future Crew, Twilight Zone, Renaissance, Triton, etc.

Assembly 2009
Assembly 2009

A maioria desses DemoGroups eram compostos por pessoas dos países nórdicos, especialmente finlandeses. A impressão que dava era que quanto mais gelado o país, melhores eram as demos… talvez seja um efeito de não poder sair pra badalar devido ao frio intenso 😀

Com o passar do tempo, campeonatos anuais de demos começaram a ser organizados, como o Assembly e a The Party. Esses campeonatos reuniam diversos integrantes de vários DemoGroups, onde as demos eram apresentadas e avaliadas para se eleger as vencedoras. Criou-se até mesmo categorias de competição: 1K Intros, 4K Intros, 64K Intros, PC Demos, etc.

Unreal

Vencedora do campeonato Assembly’92, produzida pela Future Crew. Além de uma trilha sonora excepcional (© Purple Motion), tinha todos os quesitos que compõem uma boa demo. Não foi a toa que ganhou o concurso! Essa foi a primeira demo que realmente me encheu os olhos! Na época, chegamos até a exibi-la publicamente (através de um datashow) em uma palestra que demos no Colégio Piracicabano.

Li em uma entrevista, há alguns anos atrás, que o compositor (Purple Motion) havia criado toda a trilha sonora direto no computador, um Commodore64, sem ter nem ao menos um piano ou sintetizador pra ajudar! Para isso eram usados os trackers, programas que permitiam compor músicas diretamente no computador, geralmente no padrão MOD ou alguma variação dele.

Second Reality

Após ganhar o primeiro lugar no Assembly em 1992 com a Unreal, a Future Crew apresentou no Assembly’93 a Second Reality (ou Unreal 2), sua mais nova criação, trazendo gráficos e efeitos ainda mais elaborados. Algumas das ideias eram claramente uma evolução de partes da Unreal, assim como alguns objetos 3D. Ganharam o primeiro lugar, de novo!

O código fonte da Second Reality foi aberto e publicado no Github em 2.013, em comemoração ao aniversário de 20 anos!

As demos no Brasil

Infelizmente, desconheço a existência de um DemoGroup brasileiro, muito menos de algum campeonato nacional de demos. Como já comentei, naquela época a internet era para pouquíssimos, sendo mais comuns os BBS como forma de “comunidade digital” para troca de mensagens, arquivos, etc. Como SysOp, comecei a disponibilizar na WarmBoot BBS as demos que eu baixava da internet. Não demorou muito para que esses arquivos fossem parar em outros BBS do país, e com isso mais pessoas passaram à aprecia-las!

A internet também me possibilitou entrar em contato com alguns DemoGroups por e-mail, e assim a WarmBoot BBS passou a ser distribuidora oficial da FutureCrew, Renaissance e Twilight Zone, no Brasil!

Naquela época ainda tinha tempo para brincar com diferentes linguagens de programação e técnicas “baixo nível”, como programação VGA, etc. chegando inclusive a criar uma pequena intro escrita em Assembly para ser distribuída com todos os arquivos do WarmBoot BBS, a Great2!, que fazia uso de técnicas de refresh da VGA para simular uma tela kickando suavemente, enquanto uma música era tocada em background juntamente com um “VU meter” em tempo real. A música eu peguei pronta na internet, bem como o código do midi player que à executava. O executável final ficou com 6KB, apesar que “trapaceei” usando um compressor, visto que provavelmente só os dados da música já ocupavam mais que isso.

IBM/PCs não são legais…

Pelo menos não para as demos 😉 O fato é que IBM/PCs não foram projetados com a intenção de serem “centrais de entretenimento”. Na época, existiam computadores muito mais “demo friendly”, sendo o Amiga o mais conhecido… bom, pelo menos lá fora, já que não existia fabricação nacional de “clones” do Amiga, portanto, era uma raridade encontrar um por aqui.

Amiga 4000

O Amiga veio de um projeto que originalmente visava ser um video game, portanto, sempre foi focado em gráficos e som, um paraíso para os demo makers! Com isso, conseguia realizar tarefas gráficas muito mais rapidamente do que um IBM/PC. O Amiga já de cara nasceu com um sistema operacional gráfico, e usava CPUs da Motorola, os mesmos que a Apple usou no Macintosh durante um bom tempo.

Enfim, com a proliferação mundial dos micros compatíveis com IBM/PC, os demo makers acabaram desenvolvendo também demos para essa arquitetura, felizmente para nós!

Enfim, era isso que tinha pra falar… post recheado de velharia e saudosismo. Muitos irão matar saudades, outros provavelmente vão descobrir coisas que nunca ouviram falar.

Espero que a leitura tenha sido divertida e que tenha despertado a curiosidade sobre as demos. Visitem os links e terão muito mais informação sobre o assunto!

Share and Enjoy !

Registro de carro 0km pela internet

Em pleno século 21, acho inaceitável ter que recorrer a despachantes para fazer uma simples documentação de veículo 0km. O governo investe para modernizar e simplificar os processos e muitas vezes por “medo” ou “comodismo”, acabamos não usufruindo dessas mudanças e tendo gastos desnecessários. Os despachantes estão cobrando em média entre R$ 200-300 para fazer o registro, valor que muitas vezes deve incluir um “extra” para agilizar a emissão dos documentos, pois o processo é um só… não existe o jeito rápido e o lento.

Felizmente, em tempos de pandemia, o Detran-SP implementou em seu portal uma forma de fazer o registro do veículo via internet, mas a sensação que dá é que parte do processo ainda é bastante “manual”, pairando uma desconfiança se funciona ou não.

Começando pela “fase 1” do processo, onde você deve enviar a documentação básica para validação, o que inclui a nota fiscal do veiculo, contrato social da empresa (se estiver em nome de PJ – meu caso), documento de identificação pessoal, etc. e o preenchimento de um formulário bem simples, que pede informações que qualquer um consegue informar.

A primeira ressalva vem do fato de que ao enviar o formulário com os documentos anexados, é exibida apenas uma mensagem (veja a imagem abaixo) dizendo que os dados foram recebidos e que dentro de 3 dias úteis será enviado um email com as guias para pagamento de ipva/dpvat/etc. Não existe um número de protocolo que prove que você enviou a requisição, ou que possa ser consultado pra saber o andamento do processo 🙁

Enfim, 3 dias depois, recebi o email do Detran, com a Guia do IPVA e DPVAT à serem recolhidos (nenhuma delas tinha o número do renavan). Além disso, é necessário pagar a taxa do primeiro registro. Vale observar que as guias chegaram em PDF, mas fica claro que são versões digitalizadas de documentos que haviam sido impressos manualmente, ou seja, alguém no Detran imprimiu as guias, digitalizou e gerou o PDF que foi enviado por email:

Guia DPVAT digitalizada

Outra informação não tão obvia se refere à como pagar a tal taxa do primeiro registro. Imaginei que haveria algum documento/guia com código de barras, mas não! Nenhum tipo de guia foi enviada. Comecei a fuçar e vi que no site do Santander Empresas há opção de recolher essa taxa, informando apenas o CNPJ da empresa. Tentei fazer pelo internet banking, mas não consegui (bug no site do Santander) e, depois de perder mais de uma hora no telefone com atendentes que não souberam resolver o problema, resolvi ir por conta e risco até uma agência e pagar direto no caixa eletrônico (funcionou, mas não precisava ter perdido todo esse tempo… lamentável!).

De posse do comprovante de pagamento do ipva/dpvat/1º registro, começa a fase 2 do processo. Novamente, pelo portal do Detran, preenchemos outro formulario com poucas informações, anexamos os comprovantes e enviamos pra eles. Mais uma vez, não é gerado nenhum número de protocolo… apenas uma tela dizendo que receberemos um contato via e-mail dentro de 3 dias úteis.

Passados 3 dias úteis, recebi um email muito mal redigido, dizendo que o processo havia sido concluido com sucesso. A mensagem está reproduzida abaixo:

Protocolo: #########

Prezado (a) cidadão (ã),

Em resposta à sua manifestação, informamos que a documentação estácorreta e o serviço foi concluído.

Para salvar, baixar ouimprimir o licenciamento de seu veículo, acesse o portal doDETRAN.SP(www.detran.gov.br), o portal do Departamento Nacional detrânsito(Denatran, www.denatran.gov.br) ou baixe o aplicativoCarteira Digital de Trânsito – CDT (SOMENTE para pessoas físicas)nas lojas para Android e IOS.

Para incluir o licenciamentono aplicativo CDT encaminhamos também o código de segurança dodocumento que foir emitido que é: #########

Caso seja necessárioemplacar seu vículo, entre em contato com uma das empresascredenciadas ao Detran.SP

(veja a lista emwww.detran.sp.gov.br),opção no rodapé do portal “credenciados”, “Empresasemplacadoras”.

Agradecemos sua manifestação e ressaltamos a importância do seu contato para o aprimoramento dos serviços do Detran.SP.

Atenciosamente,

(nome e sobrenome do responsável pela resposta)
(cargo que ocupa)
Detran.SP
Governo do Estado de São Paulo

PS: A mensagem é assim mesmo, não é falha de copiar/colar.

Além do fato de estar redigida porcamente (a falta de espaços não é falha minha, chegou assim mesmo), dá a impressão que é uma mensagem padrão enviada no final do processo para qualquer requisitante, seja ele pessoa física ou jurídica.

Alguns problemas:

  • Não foi informado o número da autorização para estampagem (emplacamento) – sem ele não dá pra emplacar!
  • Não é informado o número do renavan, necessário para fazer praticamente qualquer coisa referente ao veículo no portal do Detran, como, por exemplo, imprimir o CRLV-e.
  • Não é mencionado que o próximo passo seria agendar a retirada do CRV no Poupatempo.
  • O carro estava em nome de Pessoa Jurídica, mas a mensagem diz que poderia emitir o CRLV-e pelo aplicativo CDT (Carteira Digital de Trânsito), ao mesmo tempo que informa que ele só serve para pessoas físicas! Porque colocar essa informação no email então?
  • Informaram um código de segurança que, no meu caso, não serviu pra nada.

Enfim, fiquei numa situação de “limbo”. Não posso emplacar porque não tenho o código de estampagem. Não posso emitir o CRLV-e porque não tenho o renavan. A única informação que eu tinha até então era a placa do veículo, que havia sido escolhida durante a fase 1. Faço o que então?

Entrar em contato com o Detran-SP é uma tarefa complicada! Todos os telefones encontrados pelo Google não funcionam mais. O formulário do “Fale Conosco” do site muitas vezes não funciona e, quando funciona, nem mesmo dá um prazo para obter a resposta (geralmente mais de uma semana). O link para falar com a ouvidoria joga você de volta pro formulário do Fale Conosco, numa óbvia tentativa de dificultar qualquer contato com a mesma. Enfim, fazem de tudo para que você desista de fazer contato, muito menos com algum ser humano.

Foi então que decidi recorrer às redes sociais. Na página do Detran-SP no facebook nem mesmo é disponibilizada a opção de enviar uma mensagem. Foi no twitter que finalmente consegui algum tipo de interação com um “ser vivo”, que por sinal me atendeu bem, solicitou alguns dados e disse que retornaria com alguma informação em breve, visto que teria que repassar esses dados para outra equipe, pois eles não tem acesso às informações dos veículos da base do Detran (?!). Como já era mais de 17h, a resposta ficou para o dia seguinte. Foi só assim que finalmente consegui o código de estampagem. No entanto, não me passaram o renavan! Disseram que o próximo passo seria agendar a retirada do CRV no PoupaTempo, e depois ir fazer o emplacamento. Fiz a solicitação de agendamento, e ainda estou aguardando a resposta. Enquanto isso não acontece, através de uma das estampadoras de placas credenciadas na cidade, consegui que eles puxassem o número do renavam pela placa do veículo, e assim finalmente emiti o CRLV-e!

Enfim, o processo de registro funcionou, mas está longe de ser algo ideal ou mesmo automatizado. O fato de (aparentemente) haver muita interação manual no trâmite do processo (por parte do Detran) dá margem a erros. Os emails “padronizados”, onde falta informação essencial para a finalização do processo, são outro problema inaceitável. A falta de um número de protocolo para poder acompanhar o processo deixa tudo ainda mais nebuloso. Para encerrar, a dificuldade de ter alguma forma de contato com um ser humano, e ter que recorrer à formularios de contato que nem sempre funcionam e cuja demora na resposta pode levar dias ou semanas, deixa tudo ainda pior.

Há muito espaço para melhoria, e espero que assim aconteça, afinal, num mundo conectado, já passou da hora do cidadão poder resolver a “BURROcracia” por conta própria, de forma fácil e ágil, sem ter que gastar ainda mais dinheiro pra isso.

Share and Enjoy !

Texas Flood

SRV Texas Flood book

Stevie Ray Vaughan foi um daqueles raros artistas que já nascem com o dom que alguns outros tentam adquirir no decorrer da vida, com estudo e dedicação, e muitas vezes sem o mesmo sucesso!

Desde cedo já se destacava dentro do blues, deixando muitos mestres como Buddy Guy, Albert King, B.B. King, Eric Clapton, etc. de queixo caído! O fato do seu irmão mais velho (Jimmie Vaughan) já se apresentar em bares quando Stevie ainda era adolescente facilitou para que ele entrasse/tocasse nesses lugares, e tivesse contato com muitas lendas do estilo.

Infelizmente, meu primeiro contato com sua música foi depois de ver a notícia da sua morte num trágico acidente de helicóptero (agosto de 1990) – detalhe: ele decidiu ir naquele helicóptero em cima da hora, depois de ser avisado que um lugar tinha ficado vago. Fico imaginando quanto mais Stevie teria pra nos oferecer se não tivesse morrido tão cedo – tinha 35 anos. Menos mal que temos um farto material oficial (e uma infinidade de bootlegs de shows) para nos manter saciados enquanto aguardamos o aparecimento de alguém tão bom quanto ele para tentar compensar a perda.

(Imagem: Paul Natkin/Getty Images)

Não existia Stevie sem o blues e sem a guitarra – essa é a única forma de descrever sua relação com o estilo e com o instrumento. Quando tocava, as três coisas se tornavam uma só! Sem nunca ter estudado música e sem saber ler partituras, seu talento era natural e num nível de excelência quase que impossível de se alcançar. É difícil imaginá-lo sem a sua famosa guitarra number one (uma Fender 1959 toda mexida). Lenny, sua primeira esposa, disse que acordava as vezes durante a noite com Stevie dormindo mas com as mãos se movimentando como se estivesse tocando a guitarra – nem dormindo ele parava de tocar 🙂

Texas Flood, além do nome do seu primeiro trabalho oficial com a Double Trouble, é o nome desse livro e também de uma das músicas que, apesar de não ser de sua autoria, ficou consagrada na sua interpretação!

O livro é bem diferente de outros que já li sobre ele, pois descreve Stevie através da visão de diversas pessoas próximas que acompanharam sua vida/carreira, ou que dividiram o palco com ele: seu irmão Jimmie, Tommy Shannon + Reese Waynes + Chris Layton (Double Trouble) e de muitos outros artistas como Buddy Guy, Eric Johnson, Joe Perry, B.B. King, etc. Ou seja, o livro foge do modelo tradicional de biografia, mas segue uma linha de tempo consistente, retratando cada uma das fases através de depoimentos de quem as viveu junto com ele. E nada passa batido, inclusive a fase mais difícil onde (pra variar) o consumo de drogas e álcool quase o matou!

Para quem toca guitarra, gosta de blues ou simplesmente ama a música, é uma ótima fonte de informação pra conhecer melhor um dos maiores ícones do estilo! Infelizmente não temos uma edição em português, mas você pode comprar a versão em inglês facilmente pela Amazon, tanto em formato digital ou em papel.

Share and Enjoy !

BBS – Um passado não tão distante, mas já quase esquecido

Quando se fala em tecnologia, o tempo parece passar mais rápido do que o normal. A evolução é tão rápida que lembrar de algo que aconteceu há 20-30 anos atrás pode ser comparado a lembrar do tempo dos dinossauros.

Obs: O artigo é cheio de links, vale a pena visita-los para se aprofundar em cada assunto.

Na década de 90, computadores tinham menos poder de processamento do que um smartphone atual, e nem estou falando dos tops de linha! Provavelmente, muitos dos nerds e youtubers de hoje não reconheceriam grande parte das siglas, abreviações e termos utilizados no mundo da computação no início da década de 90: XT, AT, 286, 386 SX, 386 DX, 486, Himem.sys, EMM386, CGA, EGA, VGA, CP/M, etc. A internet no Brasil ainda era uma recém nascida, acessível inicialmente apenas em algumas universidades públicas. Web? Não! Estamos falando de telnet, ftp, Usenet, etc.

Foi um pouco antes dessa época que os BBSes (Bulletin Board System, ou Sistema de Quadro de Avisos – numa daquelas traduções horríveis ao pé da letra) reinavam como as únicas opções de “comunidade virtual” [tá, não vou considerar o VideoTexto, 😀 ], sem saber que logo seriam dizimadas pela chegada da Internet e suas crias tão mais eficientes (e-mail, ICQ, Orkut, Netscape, etc). Os BBSes permitiam que qualquer pessoa que possuísse um computador + modem + linha telefônica pudesse baixar e enviar mensagens e arquivos, além de teclar com outros usuários em real-time através dos chats (restritos ao próprio BBS, ou seja, não era possível conversar em real-time com usuários de outros BBS). Tudo isso em “impressionantes” velocidades que variavam entre 2.400bps e 28.800bps (bps = bits por segundo!) .

Por trás de um BBS sempre havia um software gerenciador de BBS e uma pessoa, o SysOp (System Operator – Operador do Sistema). No Brasil, o software mais usado era o “RA” (Remote Access). Fui SysOp da WarmBoot BBS e, particularmente, preferi usar o Maximus e posteriormente o KBBS, sendo esse último indicado para rodar em OS/2. Geralmente, não era o gerenciador de BBS que “atendia” as ligações. Essa função era de outro software, como o FrontDoor. Era ele que atendia as ligações, verificava se era uma chamada de um usuário ou de outro BBS (para troca de pacotes), e repassava para o software apropriado continuar o “atendimento”. Alguns softwares gerenciadores já traziam um “FrontDoor” embutido.

Dentre os modems mais utilizados no Brasil estavam os da USR (US Robotics) e Hayes, sem contar os inúmeros xing-lings trazidos do Paraguai (Genius, BitCom, etc). O momento de conexão via modem era angustiante! Devido a péssima qualidade das linhas telefônicas, muitas vezes a “gritaria” do modem se perpetuava pela eternidade, na tentativa de negociar uma melhor taxa de conexão.

A troca de mensagens não era instantânea, mas era mais rápida do que usar os Correios 😀 Você conectava, via/lia as mensagens novas, respondia as que desejasse e aguardava um ou dois dias para obter sua resposta. Isso porque a maioria dos BBS trocava mensagens entre si apenas uma vez ao dia, ou melhor, de madrugada, para economizar na conta telefônica (o desconto nos pulsos de interurbanos chegava a 75%).

O processo para troca das mensagens era bem organizado. Cada BBS tinha seu node de distribuição (um outro BBS), onde se conectava para trocar as mensagens. Havia redes de mensagens responsáveis por organizar tudo isso, sendo a internacional Fidonet a maior e mais famosa! Posteriormente, surgiu no Brasil a RBT (Rede Brasileira de Teleinformática), que obteve um certo sucesso mas nunca destronou a “Fido”. Para fazer parte dessa estrutura, o BBS precisava se filiar à uma rede existente, obter seu número de cadastro e começar a participar do processo organizacional de troca de mensagens. Um número de cadastro na Fidonet seguia o padrão zone:net/node, por exemplo, 1:105/6 significa host 6 dentro da rede local de Portland Oregon (rede 105) que está na América do Norte (zona 1). Basicamente, os BBSes conectavam o node de distribuição, enviavam e recebiam as novas mensagens. Esses nodes por sua vez conectavam a outros nodes, e assim por diante, distribuindo as mensagens para todo o planeta.

Como o número de linhas telefônicas disponíveis nos BBSes costumava ser limitado (as linhas eram tão escassas e caras, que chegavam a ser alugadas em imobiliárias), era de praxe utilizar softwares para baixar e responder as mensagens enquanto se estivesse desconectado. O usuário ligava para o BBS, baixava o pacote contendo as novas mensagens ao mesmo tempo que subia as mensagens que já havia respondido quando estava desconectado, tudo através do uso de softwares “mensageiros”, como por exemplo o BlueWave.

A interface dos BBSes era de texto puro, nada de gráficos bonitinhos, janelas, etc. No máximo uma corzinha pra deixar os caracteres menos chatos. Não demorou para que programas específicos surgissem a fim de facilitar a criação das chamadas “telas ANSI”, onde se conseguia utilizar caracteres especiais e coloridos, como bordas, etc. para criar algo mais bonito do que uma simples tela preta cheias de letras e números brancos. Vale lembrar que uma configuração errada no software de comunicação já era suficiente para transformar uma linda tela ansi num indecifrável conjunto de caracteres estranhos e sem o menor sentido. Um dos editores ANSI mais usados na época era o TheDraw.

Além da troca de mensagens, os BBSes eram a fonte mais rápida para se ter acesso a arquivos e novidades. O acervo de arquivos de um BBS geralmente ficava armazenado em CDs e HDs. Um BBS “top” tinha múltiplos drives de CDROM, provendo simultaneamente diversos CDs contendo bibliotecas de arquivos. Já os BBSes mais modestos (a maioria) tinham apenas um CDROM, e criavam um cronograma onde de tempos em tempos os CDs eram trocados por outros, variando portanto o acervo de arquivos ofertado. Havia CDs com coletâneas de arquivos específicas para BBS, sendo um dos mais famosos o Night Owl.

Entre os arquivos mais populares entre os usuários estavam os GIFs que, em sua maioria, eram de mulheres nuas (que novidade!). Cindy Crawford, Claudia Schiffer, Paulina Poriskova, entre outras eram as musas da época. Obviamente nem tudo se limitava a gifs. Os freewares e sharewares eram a melhor forma de se distribuir e/ou vender softwares, em uma época onde um programa de computador não passava de alguns KBytes de tamanho. O conceito do shareware é: compartilhe o programa, teste-o e registre/pague para continuar usando. Compactadores de arquivos eram amplamente utilizados para diminuir o tamanho e tempo dos downloads. O mais usado na época era o ARJ, que oferecia taxas de compressão melhores que o ZIP, além de muitas outras funcionalidades. Era comum cada BBS adicionar um arquivo próprio (geralmente txt ou um pequeno exe/com) de propaganda, como se fosse uma assinatura dizendo: esse arquivo veio do BBS tal. Na WarmBoot BBS, adicionávamos o great2!.exe.

Além dos GIFs, freeware e sharewares, outra categoria de software começou a se disseminar nos BBS de todo o mundo: as Demos!

Demos nada mais eram do que apresentações gráficas, geralmente escritas em Assembly, onde durante a apresentação, efeitos visuais e animações 3D eram exibidos acompanhados por uma trilha sonora envolvente, sendo tudo calculado e desenhado em real-time, numa época onde os processadores rodavam em média a 40Mhz (com o turbo ligado :-D).

As Demos merecem uma atenção especial, e serão o tema de um próximo post.

Mas e quanto aos usuários? Geralmente, se associar à um BBS envolvia o pagamento de uma mensalidade. O valor dependia do “nível” que você desejasse ter dentro do BBS. Os níveis determinavam que áreas de arquivos ou mensagens poderiam ser acessadas, quanto tempo de conexão por dia você poderia utilizar e quantos KBs poderia transferir. A maioria dos BBSes oferecia alguns minutos gratuitos para que novos usuários pudessem “passear” pelos menus e pelo acervo, antes de decidir por assiná-lo. O processo de assinatura em si começou um tanto quanto manual: baixava-se e preenchia-se a mão uma ficha de cadastro que era enviada pelo correio juntamente com o cheque para assinatura. Posteriormente, foi simplificado, dispensando o envio pelo correio e aceitando transferências bancárias. Os BBSes mais poderosos/bem sucedidos aceitavam pagamento com cartão de crédito.

A conexão do usuário com o BBS era feita através de programas específicos, como o Telix. A troca de arquivos se dava através de protocolos de transferência de arquivos, sendo o ZModem (unidirecional) o mais comum. O BiModem, não tão difundido, permitia comunicação bidirecional, ou seja, podia-se enviar e receber arquivos ao mesmo tempo. O protocolo escolhido precisava ser suportado tanto pelo gerenciador de BBS como pelo programa cliente utilizado pelo usuário. Alguns BBS associavam a elevação do nível do usuário à quantidade de arquivos enviados por ele, como forma de incentivar o envio de novos arquivos e, portanto, aumentar o acervo do BBS.

Se chegou até aqui, ou é porque viveu essa época e deve estar agora muito nostálgico e cheio de saudades, ou porque é um jovem micreiro curioso que não se contenta em viver apenas o atual, mas sim saber como chegamos onde estamos. Em ambos os casos, parabéns! 😉

Com a chegada da Internet, os BBSes perderam o sentido de existir, afinal, ela oferece tudo que os BBSes ofereciam, só que de uma forma muito mais ágil, eficiente e com alcance praticamente ilimitado. Com isso, os BBSes começaram a desaparecer, sem deixar, no entanto, de marcar a história da tecnologia e a vida dos seus usuários.

Share and Enjoy !

Abbott FreeStyle Libre – cadê a responsabilidade?

Faço uso do FreeStyle Libre desde que ele foi lançado no Brasil. Nesse mesmo blog tenho inúmeros posts falando sobre minha experiência com o uso do sensor, e relatando inclusive problemas de sensores com medições erradas. Até pouco tempo atrás, a Abbott realizava as trocas dos sensores defeituosos sem custo adicional e sem “criar muito caso”, mas não é mais assim!

Durante o carnaval, o sensor que eu estava usando começou a apresentar leituras incorretas comparando com as medições com o OneTouch da J&J (tenho as fotos pra comprovar). Eu estava em um local sem telefone e sem sinal de celular, literalmente no meio do mato, portanto, não pude entrar em contato com a Abbott naquele momento para reportar o ocorrido. Felizmente levei um sensor reserva, portanto, removi (e guardei) o sensor defeituoso e apliquei um novo.

Hoje, quarta-feira, entrei em contato com a Abbott para reportar o ocorrido, e eles se negaram a substituir o sensor pelo fato de eu ter removido o sensor defeituoso do braço, o que iria contra a orientação deles. Ora, quer dizer então que eu deveria ficar com dois sensores no braço, sendo que apenas um deles estaria funcionando, até conseguir falar com a Abbott? A troco do que? É o cúmulo da falta de bom senso da empresa!

Além de todo o stress que um sensor defeituoso gera no paciente, a empresa agora se exime da responsabilidade da troca com justificativas ridículas. Vale lembrar também que o atendimento da Abbott não funciona nos 24×7, portanto, pedir que o paciente mantenha o sensor defeituoso no braço sem oferecer um canal de contato 24h é ainda mais absurdo.

Espero que a empresa reveja esse posicionamento CONTRA seus clientes. Já não bastasse a quantidade de sensores com defeito, criar ainda mais dificuldade para “amenizar” uma situação provocada pela falta de qualidade do seu produto parece ser uma ótima forma de perder clientes. Lamentável a forma que a empresa está conduzindo essas situações.

Que venha a concorrência!

PS: Abri uma reclamação no ReclameAqui sobre esse episódio específico.

Share and Enjoy !

1 2 3 4 83