quinta-feira, março 30, 2006

Yes, nós temos livrarias!

Sou fã de longa data da Amazon, e costumo elogiá-la com frequência. Entretanto, sou fã de mais longa data da Livraria Cultura, desde quando não existia a Internet e a única loja deles era no Conjunto Nacional.

Dando uma olhada ontem, percebi uma novidade: livros usados. Diferente da Amazon, que somente intermedia a venda de livros usados, a Cultura recompra livros em bom estado (comprados nos últimos 6 meses) por 25% do preço original e os revende. Fiz uma experiência com o mais recente Asterix e recebi um exemplar em excelente condições pela metade do preço. E a entrega foi no mesmo dia (coloquei o pedido às 12:50, saiu de lá às 15:14 e foi entregue no começo da noite).

Reforço a minha sugestão de sempre: antes de comprar um livro na Amazon, dê uma pesquisada nas livrarias nacionais.

quarta-feira, março 29, 2006

Covers, versões, remakes etc

Ontem (28/mar/06) , o Jornal da Tarde falava um pouco sobre covers, na esteira de apresentações no Sesc Santana de bandas covers dos Beatles, The Who e Mutantes.

Conforme detalhado no link acima, covers não são uma novidade e existe uma certa polêmica sobre como catalogá-los. Alguns interpretes tentam copiar até a aparência do interprete original (como a maioria dos Elvis impersonators). Outras se concentram em procurar reproduzir ao vivo o som original (por exemplo, o The Australian Pink Floyd Show). Alguns grupos até tentam reproduzir mais de uma banda ao mesmo tempo (como a Beatallica).

Em alguns casos, o material original é usado apenas como ponto de partida. Isto funciona particularmente bem com as músicas dos Beatles, onde é bastante difícil fazer algo melhor com um arranjo parecido com o original. Como exemplo, recomendo o disco Tribute do Rick Wakeman, que você encontra por aí por menos de R$10.

quarta-feira, março 15, 2006

A Dura Vida de Usuário de Computador

Nos artigos americanos é bastante comum se referirem à mãe com um exemplo de usuário comum. No meu caso, minha mãe (felizmente) não usa computador. Entretanto, meu pai usa. Não é um exatamente um usuário comum, mas sofre com frequência com as coisas incompreensíveis que os softwares fazem.

Há pouco mais de um ano, ele comprou o Norton System Works. No começos dos anos 80, Peter Norton era um colunista da recém criada PC magazine que colocou à venda um utilitário para recuperar arquivos apagados. Ao primeiro utilitário se seguiram outros, surgindo o Norton Utilities. Com o passar dos anos os utilitários passaram do DOS para o Windows, a empresa foi comprada pela Symantec e até a tradicional foto do Peter Norton de braços cruzados sumiu dos anúncios e embalagens.

Algum tempo atrás o System Works começou a reclamar que uma assinatura estava vencida. segundo as instruções da tela, meu pai acabou caindo na loja on line, onde comprou e fez o download de uma atualização do System Works. Entretanto, o software continuou reclamando da assinatura e meu pai acabou comprando também a renovação de assinatura do antivirus em separado (ele achou que era apenas R$39, mas no caso da renovação de assinatura os preços no site brasileiro são em US$!). Entretanto, o software continuou reclamando que a assinatura estava vencida. Além disso, volta e meia aparecia uma tela do Windows Installer, tentando instalar algo. Após algum tempo aparecia uma mensagem de erro dizendo que o arquivo de instalação devia ser rodado a partir do Setup. Foi neste ponto que ele entregou os pontos e me chamou.

O primeiro ponto que eu percebi foi que o System Works não estava atualizado. A primeira ideia foi tentar rodar novamente o instalador. Entretanto, meu pai não sabia aonde ele tinha sido colocado. Na FAQ do site da Symantec as soluções para este problema (aparentemente comum) são olhar no diretório selecionado no Save As ou então, se o usuário souber o nome do arquivo do instalador, usar o File Search. É claro que se meu pai soubesse em qual diretório tinha recebido o arquivo nós não precisaríamos olhar no FAQ. E se eles próprios não sabem dizer o nome do arquivo, como esperar que nós soubessemos? (No final o arquivo se chama Setup.exe, como dezenas de outros, portanto o File Search não seria muito útil). O e-mail de confirmação do pedido tem um link para refazer o download, com as instruções de digitar o número do pedido e a senha. É claro que na página apontada pelo link não tinha nenhum lugar para fazer downloda ou entrar com estas informações. Após navegar por algumas páginas achamos a página de download, conseguimos lembrar a senha e fazer o download do Setup.exe.

O Setup instala um gerenciador de download que faz o download do software propriamente dito (quase 100M). Pausa para visitar a geladeira. Terminado o download é hora da instalação (seguida de um tradicional restart). O passo seguinte (automático, como tudo mais) é ativar e registrar o produto. Entretanto, o micro do meu pai não se conecta diretamente à internet quando entra no ar, é preciso chamar o "discador" do Speedy manualmente (um procedimento teoricamente sensato). Logo a primeira tentativa não teve sucesso. Feita a conexão à internet, foi preciso umas 3 tentativas para ter sucesso na conexão ao servidor da Symantec. O programa apresenta então um a lista de providências 'urgentes' a serem tomadas. A primeira é atualizar o software que acabou de ser baixado. É claro que isto não inclui as definições atualizadas de virus, que são um download a parte.

Bem, resumindo uma longa história, foram cerca de 2 horas para conseguir instalar o System Works. O Windows Installer parou de reclamar, a assinatura está renovada. Tem agora um ícone imenso na barra de programas e o tempo de boot passou de imenso para quase insuportável.

E daqui a 12 meses a assinatura vai acabar de novo...

segunda-feira, março 13, 2006

Protocolos de Comunicação

Um dos trabalhos que andei fazendo envolveu implementar o protocolo XModem em coletores de dados. Os protocolos de comunicação são algo que me facinam há muito tempo (afinal, os meus dois primeiros empregos estavam relacionados a comunicação de dados).

Um protocolo de comunicação é um conjunto de convenções usado para mover informações entre dois equipamentos. Os principais objetivos de um protocolo é cuidar do endereçamento (no caso de ligações multiponto) e garantir a integridade das informações. Embora isto não seja muito visível atualmente, a comunicação à distância está sujeita a grande quantidade de erros. A maioria dos equipamentos atuais (inclusive modems) possuem protocolos embutidos que detectam e recuperam erros de forma quase transparente. No começo da comunicação via modem, os erros de comunicação eram mais evidentes. Antes da internet, a vida on-line era feita através das BBSs (computer Bulletin Board Systems) que enviavam os textos sem protocolo, era comum caracteres sumirem, mudarem ou mesmo surgirem do nada. Um bom protocolo de comunicação precisa ter uma boa resistência a estas ocorrências.

A maioria dos protocolos de comunicação se baseiam nos mesmos conceitos. O primeiro destes conceitos é um pacote. O início de um pacote é normalmente marcado por um caracter especial. O final de um pacote pode ser determinado de três formas básicas: tamanho fixo em função do tipo de pacote, um campo de tamanho dentro do pacote ou um caracter especial no fim. Para detectar erros, é comum acrescentar-se ao final do pacote um ou mais bytes que são calculados a partir dos demais. O receptor recalcula estes bytes e confere com os recebidos, se não forem iguais é porque um erro ocorreu. Exemplos comuns de detecção de erro são os checksums (soma desprezando vai-um) e os crcs (cyclic redundancy codes). Alguns sistemas utilizam códigos de correção de erro (ECC) que além de detectar erros pode corrigir uma parte deles. O mais comum entretanto, é recuperar uma situação de erro solicitando a retransmissão do pacote. Na forma mais simples, a cada pacote recebido o receptor envia um caracter que indica se o pacote foi recebido corretamente (ACK - Acknoledge) ou com erro (NAK - NonAcknoledge). Para tratar o caso em que um ACK, NAK ou pacote é perdido no meio do caminho normalmente os pacotes são numerados e as recepções são temporizadas. Por exemplo, se o transmissor envia o pacote 31 e o receptor o recebe corretamente mas o ACk é perdido, o transmissor irá dar um timeout e re-enviar o pacote 31. O receptor ignora o pacote duplicado e re-envia o ACK para que o transmissor envie o pacote seguinte.

Como descrito acima, é comum os protocolos darem significado especial para alguns códigos. A tabela ASCII reflete isto, reservando os primeiros 32 códigos para os caracteres de controles, alguns como nome como Start of Transmission (STX), Start of Header (SOH), End of Text (ETX), Acknoledge (ACK) e Non-Acknoledge (NAK). Existem dois tratamentos comuns para os códigos de controle presentes no interior dos pacotes (nos dados). O mais comum é permitir a presença de caracteres de controle dentro de pacotes; isto é mais simples e eficiente porém pode causar problemas quando ocorre algum erro e um caracter de dado é tratado erroneamente como caracter de controle. Outra opção é utilizar um caracter de prefixo (o código ASCII tem o DLE com esta finalidade). Por exemplo, um protocolo pode convencionar que para enviar um SOH nos dados deve ser enviado DLE A e que para enviar DLE deve ser enviado DLE P ou DLE DLE.

Uma outra coisa impressionante é como determinados protocolos criados de forma despretenciosa acabam virando padrões e se mantendo vivos por décadas. O protocolo XModem foi criado nos anos 70, por uma pessoa que queria passar arquivos de um micro para outro e permanece em uso até hoje, apesar de ter uma série de limitações.

A implementação de protocolos envolve conceitos e técnicas interessantes de programação. Em ambientes sem multiprogramação muitas vezes o programa precisa analisar os caracteres recebidos um a um; após examinar cada caracter precisa retornar a um loop principal onde outras funções são tratados. Exemplificando em um pseudo C:

// loop principal
while ( )
{
  TrataTeclado ();
  AtualizaTela ();
  if (RecebeuCaracter)
    TrataCaracter ();
  ...
}

Neste caso é inevitável implementar o protocolo como uma máquina de estados. Por exemplo, o pacote básico do XModem começa com um caracter SOH e tem 132 caracteres:

enum { ESPERANDO_SOH, RECEBENDO_PACOTE } estado = ESPERANDO_SOH;
byte pacote [132];
int i;

TrataCaracter (byte c)
{
  switch (estado)
  {
    case ESPERANDO_SOH:
      if (c == SOH)
      {
        estado = RECEBENDO_PACOTE;
        i = 0;
        pacote[i++] = c;
      }
      break;

    case RECEBENDO_PACOTE:
      pacote[i++] = c;
      if (i == 132)
      {
        TrataPacote();
        estado = ESPERANDO_SOH;
      }
      break;
  }
}

Em um ambiente multitarefa, é possível fazer algo mais legível como:

byte pacote [132];
int i;

RecebePacote ()
{
  While (RxCar() != SOH)
    ;
  pacote[0] = SOH;
  for (i = 1; i < 132; i++)
    pacote[i] = RxCar ();
  TrataPacote ();
}

(Obviamente estes exemplos são artificialmente simples, existem variações do XModem , não estou tratando timeouts, etc.)

No caso de você estar desenvolvendo para um sistema sem sistema operacional (um com sistema capenga como o DOS), você provavelmente vai ter uma fila para sincronizar a recepção em tempo de interrupção com o consumo dos bytes. Se você quiser implementar multitarefa por contra própria, vai ter que implementar um semáfaro para a fila (neste caso o RxCar() acima faz uma operação P na fila e fica bloqueado se a fila estiver vazia, até que a interrupção coloque um caracter na fila e faça um operação V).

Se tudo isto parece longe do seu dia a dia, lembre-se que você está lendo isto em um site através (no mínimo) dos protocolos TCP/IP.

quarta-feira, março 08, 2006

Delphi has left the building


A notícia é velha, mas só a vi agora; a Borland vai sair do mercado de IDE (Ambiente Integrado de Desenvolvimento) e está procurando um comprador para o Delphi, JBuilder e C++ Builder.

A Borland é uma empresa que nasceu mais ou menos na mesma época que o PC e nos anos 80 conseguiu criar uma imagem muito boa. Seus primeiros produtos (Turbo Pascal, Sidekick e SuperKey) logo se tornaram best sellers, com preços acessíveis (olhando numa revista de 86, o Turbo Pascal 3.0 custava $99.95 enquanto que o Microsoft C 4.0 custava $319) e o "Borland No-nonsense License" (trate o software como um livro). A Borland popularizou algumas categorias de software, como IDE (o Microsoft C 4.0 funcionava por linha de comando) e TSR (Terminate e Stay Resident).

No final dos anos 80, a Borland sonhou alto e lançou não somente outras linguagens (como o Turbo C, Turbo Prolog e até o Turbo Basic) como uma planilha (Quattro), um gerenciador de banco de dados (Paradox) e um editor de texto (cujo nome me falha). No começo dos anos 90 (antes do surgimento do Visual Basic, abrindo a programação Windows para todos), a Borland conseguiu a façanha de ter o melhor ambiente de desenvolvimento para o Windows 16 bits, com o Borland C++. Ainda nesta época, lançou o Turbo Pascal for Windows, que veio a se tornar o Delphi.

O Delphi sempre contou com características de respeito. Juntou à facilidade RAD do Visual Basic uma linguagem estruturada orientada a objeto. Fez a transição dos 16 para os 32 bits e, mais recentemente para o .Net (algo que o Visual Basic não conseguiu). Desde o começo foi capaz de gerar código nativo e de pequeno tamanho (para ter uma idéia, a primeira versão Windows do software de imposto de renda cabia num disquete, a versão deste ano tem 3 Mbytes). Até mesmo suporte a Linux o Delphi chegou a ter. Apesar disto, a popularidade do Delphi nunca foi imensa.

Embora ainda exista uma esperança da Borland voltar atrás (como foi na mudança de nome para Inprise) ou de achar um comprador que consiga pelo menos manter a base atual de fãs do Delphi, o mais provável é que o Delphi passe a ser um produto de nicho, se defasando ao longo do tempo. É claro que vai demorar muito para acabar (afinal, ainda vemos aplicações Clipper em uso), mas vai ser cada vez mais arriscado desenvolver em Delphi.

E com isto as opções para desenvolvimento de aplicações "nativas" ficarão ainda mais limitadas. Tirando as alternativas "livres", não sobra muita coisa além do Visual C++ da Microsoft. Para aplicações do tipo formulários + banco de dados, o futuro parece ser Java e .Net. Daqui a alguns anos, para usar o programa de imposto de renda muita gente terá que fazer um download de dezenas de megabytes para instalar a máquina virtual Java ou o framework .Net atualizado.

Um último ponto a pensar é a questão da influência do código "livre" na decisão da Borland. No caso do JBuilder, parece bastante claro que a Borland perdeu clientes para o Eclipse. Apesar do discurso anti-Microsoft de muitos proponentes do "software livre", as empresas menores e os produtos de nicho sofrem muito mais com esta "concorrência". E, como resultado, se acentua mais a concentração do mercado em um ou poucos produtos.