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.
quinta-feira, março 30, 2006
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.
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.
sexta-feira, março 17, 2006
Segundo Encontro de Programadores C e C++ em São Paulo
Já está agendado o Segundo Encontro de Programadores C e C++ em São Paulo: Sábado, 25/03/06 a partir das 14:00 na Casa do Espeto. Maiores detalhes no Wiki C/C++.
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...
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.
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.
domingo, fevereiro 12, 2006
Crosby, Stills & Nash
Embora não muito conhecido no Brasil, o CS&N foi aclamado como 'supergrupo' desde que surgiu em 68. Com uma mistura de rock e folk, ele se destaca pelas harmonias vocais e pelas canções engajadas. David Crosby é um hippie californiano que começou a ficar famoso no grupo The Byrds. Stephen Stills é o sulista que se juntou a Neil Young no Buffalo Springfield, é um grande guitarrista (embora às vezes exagere na pose). Graham Nash é o ingles que fez parte do Hollies; suas canções, embora simples do ponto de vista instrumental, tem aquela qualidade de tocar fundo nas pessoas.
Tenho 2 DVDs (nacionais) deles. O primeiro é Daylight Again, gravado de um show feito em 1982 (a contracapa diz 83) na esteira do sucesso do disco com o mesmo nome. Um grande show, com uma grande banda de apoio. O único senão é a aparência do Crosby, completamente 'chapado', imóvel com os olhos fixos ou fechados. Estranhamente, isto não afetou a sua voz. Para compensar, Stills está em plena forma e aproveita bem um pequeno arsenal de guitarras. Entre os vários destaques, preste atenção em You Don't have To Cry, foi nesta música que, em 68, pela primeira vez eles experimentaram cantar juntos. Fica claro porque eles decidiram na hora formar um grupo.
O outro DVD é The Acoustic Concert, um show de 1991. Embora eles próprios chamem o show de Acústico, na maior parte Stills está tocando uma guitarra elétrica. Um descrição mais exata é que é show só com eles, sem banda de apoio, só as vozes e guitarras (e um piano em algumas músicas). O resultado é de literalmente arrepiar. Crosby está ótimo, tendo se desintoxicado na marra através de alguns meses na prisão.
Quem quiser ouvir amostras gratuitas do som deles, tem algumas músicas para download no 4WaySite (destaque para Wind On The Water). No Amazon tem um dowload gratuito de uma música mais recente do Nash. Quem quiser saber a história completa do CS&N, tem um exelente biografia de Dave Zimmer.
Tenho 2 DVDs (nacionais) deles. O primeiro é Daylight Again, gravado de um show feito em 1982 (a contracapa diz 83) na esteira do sucesso do disco com o mesmo nome. Um grande show, com uma grande banda de apoio. O único senão é a aparência do Crosby, completamente 'chapado', imóvel com os olhos fixos ou fechados. Estranhamente, isto não afetou a sua voz. Para compensar, Stills está em plena forma e aproveita bem um pequeno arsenal de guitarras. Entre os vários destaques, preste atenção em You Don't have To Cry, foi nesta música que, em 68, pela primeira vez eles experimentaram cantar juntos. Fica claro porque eles decidiram na hora formar um grupo.
O outro DVD é The Acoustic Concert, um show de 1991. Embora eles próprios chamem o show de Acústico, na maior parte Stills está tocando uma guitarra elétrica. Um descrição mais exata é que é show só com eles, sem banda de apoio, só as vozes e guitarras (e um piano em algumas músicas). O resultado é de literalmente arrepiar. Crosby está ótimo, tendo se desintoxicado na marra através de alguns meses na prisão.
Quem quiser ouvir amostras gratuitas do som deles, tem algumas músicas para download no 4WaySite (destaque para Wind On The Water). No Amazon tem um dowload gratuito de uma música mais recente do Nash. Quem quiser saber a história completa do CS&N, tem um exelente biografia de Dave Zimmer.
Advinhe o Filme
Um dos recursos pouco aproveitados da Sky é a possibilidade de ver um resumo curto do filme que está sendo apresentado. Poderia ser útil para escolher o filme, e certamente ajuda para confirmar se um determinado filme é o que estamos pensando ou um homônimo.
Ontem eu vi um filme cujo resumo era Família rica, de hábitos elegantes mas pouco convencionais, tem sua tranquilidade ameaçada quanto suposto tio desaparecido se infiltra em sue lar. Qual era o filme? A Familia Adams... (vai passar de novo hoje)
Ontem eu vi um filme cujo resumo era Família rica, de hábitos elegantes mas pouco convencionais, tem sua tranquilidade ameaçada quanto suposto tio desaparecido se infiltra em sue lar. Qual era o filme? A Familia Adams... (vai passar de novo hoje)
O Fim da AOL Brasil
Ando tão desligado que só fiquei sabendo do fim da AOL Brasil quando recebi o aviso que o meu e-mail vai sumir daqui a pouco mais de um mês.
Morando em Osasco (a 1 Km da fronteira com São Paulo) eu não tinha muitas opções quando comecei a acessar a internet, pois os grandes provedores não tinha número local (só muito recentemente ligação para São Paulo deixou de ser interurbano). Além disso, sou cliente do Itau o que dava direito a uma mensalidade reduzida.
Por tudo isso dava para aguentar o uso de software não padrão e as dificuldades de acesso ao e-mail pelo Outlook. Aliás, desde que coloquei banda larga em casa, eu só usava o e-mail, o discador da AOL nem está instalado nos micros. Continuei assinate por preguiça de sair acertando o endereço de e-mail nos vários serviços que uso.
Aparentemente inundar as pessoas com CDs e firmar parcerias com o Itaú e o Mac Donnald's não foi suficiente para a AOL Brasil dar lucro.
Morando em Osasco (a 1 Km da fronteira com São Paulo) eu não tinha muitas opções quando comecei a acessar a internet, pois os grandes provedores não tinha número local (só muito recentemente ligação para São Paulo deixou de ser interurbano). Além disso, sou cliente do Itau o que dava direito a uma mensalidade reduzida.
Por tudo isso dava para aguentar o uso de software não padrão e as dificuldades de acesso ao e-mail pelo Outlook. Aliás, desde que coloquei banda larga em casa, eu só usava o e-mail, o discador da AOL nem está instalado nos micros. Continuei assinate por preguiça de sair acertando o endereço de e-mail nos vários serviços que uso.
Aparentemente inundar as pessoas com CDs e firmar parcerias com o Itaú e o Mac Donnald's não foi suficiente para a AOL Brasil dar lucro.
sexta-feira, fevereiro 10, 2006
O Enigma do Quatro
Faz quase um mês desde o último post. Não foi falta de assunto, preguiça ou férias em uma ilha paradisíaca, foi excesso de trabalho mesmo.
Apesar disto, sobrou tempo para ler O Enigma do Quatro. Seguindo a moda atual, é um livro sobre um mistério da Renascença. A contra capa possui uma inevitável comparação elogiosa com Dan Brown.
Não consegui me entusiasmar muito com o livro. Ele me pareceu muito arrastado, só pegando impulso no quarto final. O estilo também não faz o meu gênero, muitos flashbacks para contar o interrelacionamento entre os personagens e o avanço na solução do enigma. Para completar as mais de 400 páginas da edição nacional, muitas descrições de prédios de Princeton.
Decididamente, em termos de mistérios da Renascença prefiro a primeira temporada de Alias.
Apesar disto, sobrou tempo para ler O Enigma do Quatro. Seguindo a moda atual, é um livro sobre um mistério da Renascença. A contra capa possui uma inevitável comparação elogiosa com Dan Brown.
Não consegui me entusiasmar muito com o livro. Ele me pareceu muito arrastado, só pegando impulso no quarto final. O estilo também não faz o meu gênero, muitos flashbacks para contar o interrelacionamento entre os personagens e o avanço na solução do enigma. Para completar as mais de 400 páginas da edição nacional, muitas descrições de prédios de Princeton.
Decididamente, em termos de mistérios da Renascença prefiro a primeira temporada de Alias.
sábado, janeiro 14, 2006
Maigret
Descobri neste começo de ano que a editora L&PM está publicando os livros do inspetor Maigret em formato de bolso (e preços acessíveis).
Sou fã de Maigret de longa data. O estilo dos livros é diferente dos livros policiais mais conhecidos (como os da Agata Christie). A ênfase está mais na ambientação da trama e na caracterização dos personagens que no crime em si. O final, normalmente, revela uma trama sórdida e personagens com suas vidas dominadas pelas fraquezas humanas. Outra diferença é que Maigret é um policial, o que dispensa as frágeis reviravoltas e coincidências comuns nos livros policiais para levar o detetive ao crime. É também bastante curioso ver o funcionamento da policia francesa e seu estreito relacionamento com a justiça (para começar, Maigret trabalha na Polícia Judiciária).
Sinto também uma certa semelhança entre o comportamente de Maigret durante a investigação e o meu próprio comportamento quando estou debugando um problema, particularmente a sensação de peso e hesitação.
Nem todos irão apreciar o estilo de Georges Simenon, e talvez seja daqueles que só se começa a apreciar depois de ler mais de um. Os interessados não devem ter dificuldade de achar os livros em livrarias (por exemplo, Cultura e Siciliano) e bancas. O livro que acabo de ler é A Fúria de Maigret, na mesma coleção tem Maigret e o Homem do Banco, que também recomendo (a parte em que Maigret vai obter informações sobre o morto no seu local de trabalho é imperdível).
Sou fã de Maigret de longa data. O estilo dos livros é diferente dos livros policiais mais conhecidos (como os da Agata Christie). A ênfase está mais na ambientação da trama e na caracterização dos personagens que no crime em si. O final, normalmente, revela uma trama sórdida e personagens com suas vidas dominadas pelas fraquezas humanas. Outra diferença é que Maigret é um policial, o que dispensa as frágeis reviravoltas e coincidências comuns nos livros policiais para levar o detetive ao crime. É também bastante curioso ver o funcionamento da policia francesa e seu estreito relacionamento com a justiça (para começar, Maigret trabalha na Polícia Judiciária).
Sinto também uma certa semelhança entre o comportamente de Maigret durante a investigação e o meu próprio comportamento quando estou debugando um problema, particularmente a sensação de peso e hesitação.
Nem todos irão apreciar o estilo de Georges Simenon, e talvez seja daqueles que só se começa a apreciar depois de ler mais de um. Os interessados não devem ter dificuldade de achar os livros em livrarias (por exemplo, Cultura e Siciliano) e bancas. O livro que acabo de ler é A Fúria de Maigret, na mesma coleção tem Maigret e o Homem do Banco, que também recomendo (a parte em que Maigret vai obter informações sobre o morto no seu local de trabalho é imperdível).
terça-feira, janeiro 10, 2006
Mais um Exame de Certificação
Em 15 de abril de 2003 comprei na Amazon o meu primeiro lote de livros sobre .NET. Entre eles, o MCAD/MCSD Training Guide do Amit Kalani para o exame 70-315 (Developing and Implementing Web Applications with Visual C# and Visual Studio .Net). Meu objetivo, na época, era obter o MCAD até o final do ano. Considerando os exames em que já fui aprovado para obter o MCSD Visual Studio 6, preciso, além do 70-315, apenas mais um exame (70-320).
O ritmo do estudo oscilou conforme a pressão do trabalho e da família. Na metade de 2003 mudei as minhas prioridades e passei a estudar para o exame 70-300 (Analyzing Requirements and Defining Microsoft .NET Solution Architetures), a fim de aproveitar uma oferta de exame gratuito para quem já tinha a certificação em MCSD. Após passar no exame, voltei à inconstância do estudo. De alguma forma, 2004 passou sem que eu prestasse qualquer exame.
Em agosto de 2005, ganhei um voucher de exame gratuito em uma das promoções do TechNet Brasil e defini como nova meta para o MCAD o final de 2005. Em novembro, com o lançamento do Visual Studio 2005, a Microsoft anunciou novos exames (a serem disponibilizados em 2006) e uma mudança radical nas certificações de desenvolvimento. Em meados de dezembro, descobri que o voucher valia apenas até 8 de janeiro. Com este incentivo adicional, entrei em um ritmo acelerado de estudo e no dia 4 passado prestei e passei o exame (agora quase obsoleto).
Para quem não conhece o processo de certificação da Microsoft, eu diria que na essência eles consistem em passar em exames. Você estuda da forma que achar melhor, agenda o exame em um centro autorizado, vai no dia combinado, responde às perguntas no micro e se acertar um número mínimo de questões passou no exame. Tendo passado em um exame, você é um MCP (Microsoft Certified Professional), com direito a diploma, cartão e broche. Determinadas combinações de exames dão direito a títulos adicionais (com diploma, cartão e broche).
A pergunta mais comum sobre certificação é se vale a pena. A minha resposta é que depende do que você espera da certificação. No meu caso, eu comecei a me interessar por certificação no final de 2001, em um momento em que estava com grandes dúvidas sobre a minha carreira. Meus objetivos eram dois: mostrar a mim mesmo que eu era capaz de passar nos exames e aumentar a abrangência dos meus conhecimentos (já que eu trabalhei sempre em áreas bem específicas). Tenho certeza que atingi estes dois objetivos. Não percebi os efeitos colaterais da certificação apregoados por alguns, como aumento expressivo da remuneração, veneração pelos colegas de trabalho e fim da queda de cabelo.
Um outro mito sobre certificação é a sua relação direta com a experiência profissional com o assunto. Eu diria um profissional com anos de experiência terá dificuldades nos exames, pelo fato da experiência tender a se concentrar em algumas tecnologias e os exames serem muito abrangentes. Olhando pelo outro lado, é plenamente possível passar num exame sem ter experiência profissional no assunto. No meu caso específico, tenho usado os exames como incentivo para estudar assuntos com os quais não tenho contato no dia-a-dia e os resultados tem sido positivos.
Para quem ainda pretender prestar o exame 70-315, alguns comentários. O livro do Amit Kalami foi muito bom, além de preparar para a prova ele ensina bastante coisa para quem for usar C# no dia-a-dia. Recomendo fazer toda a parte prática do livro (o que acabei não fazendo na correria final). O exame consta de 43 questões de múltipla escolha, o software deixa bem claro quando é esperada mais de uma alternativa e não deixa selecionar a mais ou a menos. O tempo é mais que suficiente, e ainda se ganha mais 1/2 hora pelo exame estar em inglês. A nota mínima é 700, ou seja, você precisa acertar pelo menos 31 das 43 questões (supondo que não se possa acertar parcialmente uma questão). A redação das questões sofre muito da tentativa de dar uma roupagem "prática" às questões, o que resulta numa enxurrada de informações desnecessárias. Por outro lado, ocasionalmente uma informação vital está escondida no meio do texto, portanto você precisa ler tudo com muita atenção. As questões em si são um segredo industrial da Microsoft e você precisa aceitar um NDA antes de começar o exame. Como levo a sério NDAs, digo apenas que o livro do Amit Kalami cobriu bem o assunto. O nível de dificuldade é suficiente para fazer a maioria das pessoas suar, é importante não entrar em pânico ao ficar em dúvida e lembrar que você não precisa acertar todas as questões para ser aprovado.
Agora é decidir se vou tentar fazer o 70-320. Apesar de também estar obsoleto, o livro está na minha estante pegando poeira...
Enquanto isso, tem gente já fazendo os exames da nova geração.
O ritmo do estudo oscilou conforme a pressão do trabalho e da família. Na metade de 2003 mudei as minhas prioridades e passei a estudar para o exame 70-300 (Analyzing Requirements and Defining Microsoft .NET Solution Architetures), a fim de aproveitar uma oferta de exame gratuito para quem já tinha a certificação em MCSD. Após passar no exame, voltei à inconstância do estudo. De alguma forma, 2004 passou sem que eu prestasse qualquer exame.
Em agosto de 2005, ganhei um voucher de exame gratuito em uma das promoções do TechNet Brasil e defini como nova meta para o MCAD o final de 2005. Em novembro, com o lançamento do Visual Studio 2005, a Microsoft anunciou novos exames (a serem disponibilizados em 2006) e uma mudança radical nas certificações de desenvolvimento. Em meados de dezembro, descobri que o voucher valia apenas até 8 de janeiro. Com este incentivo adicional, entrei em um ritmo acelerado de estudo e no dia 4 passado prestei e passei o exame (agora quase obsoleto).
Para quem não conhece o processo de certificação da Microsoft, eu diria que na essência eles consistem em passar em exames. Você estuda da forma que achar melhor, agenda o exame em um centro autorizado, vai no dia combinado, responde às perguntas no micro e se acertar um número mínimo de questões passou no exame. Tendo passado em um exame, você é um MCP (Microsoft Certified Professional), com direito a diploma, cartão e broche. Determinadas combinações de exames dão direito a títulos adicionais (com diploma, cartão e broche).
A pergunta mais comum sobre certificação é se vale a pena. A minha resposta é que depende do que você espera da certificação. No meu caso, eu comecei a me interessar por certificação no final de 2001, em um momento em que estava com grandes dúvidas sobre a minha carreira. Meus objetivos eram dois: mostrar a mim mesmo que eu era capaz de passar nos exames e aumentar a abrangência dos meus conhecimentos (já que eu trabalhei sempre em áreas bem específicas). Tenho certeza que atingi estes dois objetivos. Não percebi os efeitos colaterais da certificação apregoados por alguns, como aumento expressivo da remuneração, veneração pelos colegas de trabalho e fim da queda de cabelo.
Um outro mito sobre certificação é a sua relação direta com a experiência profissional com o assunto. Eu diria um profissional com anos de experiência terá dificuldades nos exames, pelo fato da experiência tender a se concentrar em algumas tecnologias e os exames serem muito abrangentes. Olhando pelo outro lado, é plenamente possível passar num exame sem ter experiência profissional no assunto. No meu caso específico, tenho usado os exames como incentivo para estudar assuntos com os quais não tenho contato no dia-a-dia e os resultados tem sido positivos.
Para quem ainda pretender prestar o exame 70-315, alguns comentários. O livro do Amit Kalami foi muito bom, além de preparar para a prova ele ensina bastante coisa para quem for usar C# no dia-a-dia. Recomendo fazer toda a parte prática do livro (o que acabei não fazendo na correria final). O exame consta de 43 questões de múltipla escolha, o software deixa bem claro quando é esperada mais de uma alternativa e não deixa selecionar a mais ou a menos. O tempo é mais que suficiente, e ainda se ganha mais 1/2 hora pelo exame estar em inglês. A nota mínima é 700, ou seja, você precisa acertar pelo menos 31 das 43 questões (supondo que não se possa acertar parcialmente uma questão). A redação das questões sofre muito da tentativa de dar uma roupagem "prática" às questões, o que resulta numa enxurrada de informações desnecessárias. Por outro lado, ocasionalmente uma informação vital está escondida no meio do texto, portanto você precisa ler tudo com muita atenção. As questões em si são um segredo industrial da Microsoft e você precisa aceitar um NDA antes de começar o exame. Como levo a sério NDAs, digo apenas que o livro do Amit Kalami cobriu bem o assunto. O nível de dificuldade é suficiente para fazer a maioria das pessoas suar, é importante não entrar em pânico ao ficar em dúvida e lembrar que você não precisa acertar todas as questões para ser aprovado.
Agora é decidir se vou tentar fazer o 70-320. Apesar de também estar obsoleto, o livro está na minha estante pegando poeira...
Enquanto isso, tem gente já fazendo os exames da nova geração.
segunda-feira, janeiro 02, 2006
Meu Primeiro Computador Pessoal
Foto: David LeoBem, não exatamente...
Ao final do primeiro ano da faculdade, eu estava fascinado com computadores e arranjei um estágio no IPT. Como mandava a tradição, no primeiro dia me puseram numa mesa com um manual de COBOL para estudar. Algum tempo depois (acho que em 1979) o IPT adquiriu um Cobra 400.
O Cobra 400 era uma máquina esquisita, cuja tecnologia a Cobra adquiriu de uma empresa americana (anos mais tarde a Cobra re-projetaria o hardware e o software adotando o nome Cobra 400 II). Embora fosse às vezes mencionado como um mini-computador, o Cobra 400 era na realidade um sistema de data entry capaz também de executar aplicações. Internamente usava um microprocessador de 8 bits (Intel 8080) com 64 Kbytes de Ram. Suportava até oito terminais (o do IPT tinha 4), cada um com uma tela de 8 linhas de 64 colunas (mapeadas nos 64K de Ram). O armazenamento era num HD de 10 Mbyte (o disco tinha o diâmetro aproximado de um LP), controlado por um outro 8080.
Afora uma linhagem estranha (TAL II), mais voltada para programas de entrada de dados, o Cobra 400 tinha também um compilador Cobol. A primeira versão do Cobol (Level 1) era tão fraca que não tinha nem ELSE no IF e só permitia operação batch (sem interação com o usuário via terminal). A segunda versão era bem decente.
Durante os primeiros meses, a máquina era usada apenas para estudos e frequentemente a tinha só para mim (daí ser o meu primeiro "computador pessoal"). Mais adiante começou a ser usado parte do tempo para digitação e parte do tempo para o desenvolvimento de um sistema (cuja estória fica para outro dia).
Mesmo assim, ainda sobrava algum tempo para brin^H^H^H^Hestudar. O meu ponto alto foi a adaptação para o Cobra 400 de um programa em BASIC. Embora a escola usasse cartões nos cursos, já existiam alguns terminais de vídeo na USP e no IPT. Por alguns dias tivemos acesso ao B6700 e conhecemos o jogo (Colossal Cave) Adventure. Quando perdemos o acesso, ficou a vontade de jogar este tipo de jogo. O número de Dezembro de 1980 da revista Byte foi dedicado a jogos e trazia a listagem completa do jogo "Pirate's Adventure" de Scott Adams. A listagem era em BASIC, para o micro TRS-80. Após uma trabalhosa engenharia reversa, consegui re-escrever o programa no Cobol do Cobra-400 e jogar o jogo até o final.
Como disse Scott Adams no iníco do artigo da Byte, time flies.
quinta-feira, dezembro 29, 2005
Comunidade C++
Como resultado do Encontro de Programadores C++, já está no ar o site, cortesia do Rodrigo Strauss.
Não fui o único a aprender a programar com cartões perfurados...
No seu post de hoje, Joel Spolsky menciona que ele também aprendeu a programar com cartões perfurados e discute a redução da dificuldade nos cursos de C.S. das universidades americanas. A perfuradora de cartões que aparece lá é muito mais bonita que as que eu usava...
segunda-feira, dezembro 19, 2005
Revistas e Livros
Em 1976 comprei a minha primeira revista com alguma relação a computadores, a "1977 Electronic Experimenter's Handbook" da Popular Eletronics. Para quem não sabe, em 1975 a Popular Eletronics trouxe na capa o primeiro kit de microcomputador. Nos anos seguintes, comprei mensalmente a Popular Electronics e mais ocasionalmente a Radio Electronics (que também trazia artigos sobre microcomputadores).Alguns anos mais tarde, encontrei no meu estágio alguns exemplares da revista Byte. A revista Byte foi uma das mais influentes nos anos 80 e seus artigos tinham uma abrangência e profundidade que nunca mais encontrei em outras revistas. Nos anos 90 a Byte foi aos poucos piorando, eu desisti de comprar quando saiu um editorial pedindo desculpas pelas brincadeiras das edições de abril... Atualmente a Byte existe somente eletrônicamente.
Em 81 eu conheci a revista Dr Dobbs, mais dedicada a software para micros. A Dr Dobbs continua firme e forte e pode atualmente ser assinada em formato eletrônico, uma boa opção para quem não pagar um dinheirão na banca ou sofrer com a inconstância do correio.
Uma das várias colunas da revista Byte era a "User's Column". O nome da coluna, escrita por Jerry Pournelle, se deve aos relatos feitos na visão de um usuário. Entretanto, o Dr Pournelle nunca foi um usuário comum, graças a seus contatos ele sempre obteve equipamentos e softwares de ponta (muitas vezes na cortesia, mas isso nunca atrapalhou o seu senso crítico). Um dos costumes da User's Column é ter o "livro do mês" (muitas vezes dois, o de informática e o não relacionado a informática).
Tentando copiar este costume, dentro das minhas limitações, vou colocar comentários curtos sobre os livros que tiver lido. No momento acabei de ler "The HP Way" de David Packard. Este livro se concentra mais nas filosofias empresariais da HP do que na sua história, mas é uma leitura fascinante. Mesmo dando um desconto para uma eventual não-isenção do autor, fica claro que a HP foi uma empresa espetacular. Ajuda também a entender porque os herdeiros de David Packard e Bill Hewlett foram contra à associação da HP à Compaq.
Encontro de Programadores C++
Iniciativa do Rodrigo Strauss, ocorreu no sábado (17/dez) um encontro de programadores C++. Foram mais de quatro horas trocando experiências e contando "causos". A idéia é repetir o evento a cada 2 a 3 meses. Assim que o Rodrigo voltar de férias vamos ter um site, aberto para todos os interessados em C e C++ (experientes ou novatos).
"Many Years Later..."
Na semana passada tivemos um encontro do pessoal dos "bons tempos" da Humana. Quem quiser se divertir procure na foto acima as pessoas que aparecem no meu post anterior (dica: o único que não compareceu foi o mais à direita na foto de 88).
domingo, dezembro 11, 2005
Desenvolvimento nos Anos 80
O meu post anterior me fez lembrar sobre as condições de desenvolvimento nos meus primeiros empregos, nos anos 80.Uma diferença em relação aos dias de hoje era a inexistência de micros sobre as mesas. Os micros ficavam normalmente em uma sala separada, o laboratório. Na foto, o laborátório da Humana Informática, em junho de 88.
No meu estágio na Scopus Tecnologia (1981), trabalhei no desenvolvimento de uma aplicação em Assembler para o microcomputador de 8 bits (MicroScopus). O desenvolvimento era feito no próprio MicroScopus; quando entrei já existia uma quantidade bem razoável deles no laboratório. Exceto por alguns problemas com a novíssima tecnologia de dupla densidade nos disquetes de 8", o desenvolvimento ocorria bastante bem. O MicroScopus trabalha apenas com disquetes de 8", winchester para micro ainda era algo novo (se bem que tinha um protótipo com disco de 5 MBytes) e os disquetes de 5 1/4" eram vistos como não profissionais.
Quando fui contratado fui alocado para o desenvolvimento do firmware de duas nova família de terminais de vídeo (Lepus e TVA 2000). O firmware também era desenvolvido em Assembler, porém em sistemas de desenvolvimento da Intel (Intelect). A Scopus possuia somente dois equipamentos (com disquetes de 8", é claro), por este motivo as edições mais pesadas eram feitas nos MicroScopus. Uma dificuldade adicional era que o hardware estava sendo desenvolvido e testado em paralelo ao software.
Posteriormente, ainda na Scopus, fui trabalhar no software do Nexus 1600, um dos primeiros PC-compatíveis nacionais. Novamente o hardware foi desenvolvido em paralelo com o software, porém neste caso tínhamos dois IBM PC (8088 4.7MHz, disquetes de 5 1/4") para desenvolvimento (em Assembler e Pascal) e teste. No final do desenvolvimento chegou um recem lançado IBM XT, com HD de 10MBytes. Depois que o projeto de hardware ficou estável (uma história interessante para um outro post) e a fábrica conseguiu alcançar a demanda, o laboratório passou a contar com uma quantidade razoável de Nexus. Para surpresa do marketing, só se usava o disquete de 5 1/4" (apesar de uma unidade externa de 8" ter sido desenvolvida) Em 85 a linguagem C começou a ser usada.
Em 1986 fui para a Humana. Uma empresa menor, incialmente tinha somente um Nexus 1600 (8088 8Mhz, 256K e dois disquetes de 5 1/4") para desenvolvimento, demonstração e treinamento. Dois computadores de 8 bits (um MicroScopus e um compatível Apple II) eram às vezes usados para edição. Com a minha chegada foi necessário adquirir mais um micro, no caso um Monydata (8088 8Mhz, 704K mas só um disquete de 5 1/4"). Para impressionar nas demonstrações do software para clientes, o monitor CGA era colorido (um luxo para a época). A Humana desenvolvia primariamente em C, usando Assembler apenas para trechos mais críticos.
Na foto de 88, da esquerda para a direita, um Itautec, o Nexus 1600, o Monydata e um Nexus 2600 (a única máquina com HD). Nos anos seguintes iriam se juntar a eles dois Microtec e um Proceda, todos com HD. Em 1989, embalada por um bom ano, a Humana comprou um lote de micros da Itautec para a sala de treinamento (com disquete) e para o desenvolvimento (com disquete e HD). A novidade destes micros era o vídeo EGA (porém os monitores eram monocromáticos). Com a chegada deles, um dos micros antigos (Proceda) foi para a minha mesa (afinal, eu era o chefe do desenvolvimento!).
quinta-feira, dezembro 08, 2005
Como eu Aprendi a Programar e Como Isto Me Afetou
Meu primeiro contato sério com programação foi no primeiro ano da faculdade, em 1977. O curso de Introdução à Computação para os alunos de Engenharia utilizava a linguagem Fortran IV. Mais que a linguagem, a forma como era feitos os exercícios práticos teve uma influência forte na minha forma de desenvolver software.
A primeira dificuldade era editar o programa. O programa era escrito em formulários especiais (folhas de codificação), que eram entregues para a digitação. Após 2 ou 3 dias, recebia-se o deck de cartões perfurados. Existia para os alunos uma sala com cerca de duas dúzias de perfuradoras, porém normalmente somente 2 estavam totalmente funcionando e várias estavam totalmente inoperantes. É claro que esta sala precisava ser compartilhada pelos 600 alunos do primeiro ano.
A USP dispunha na época de um mainframe Burroughs B6700. A interação dos alunos de toda a USP com ele era através da sala de auto-serviço (cafeteria), onde ficavam uma leitora de cartões e uma impressora. Filas para usar a sala não eram incomum.
O uso do computador era controlado por um sistema de créditos. No início do curso o aluno recebia uma certa quantidade de créditos (algo entre 35 e 45) para serem usados em todos os exercícios do semestre (4 ou 5). Cada execução de programa (tanto o compilador como o seu) consumia um crédito. Existiam limites de tempo e de linhas impressas para o interromper programa em loop ou abusos (tem a famosa estória do poster da Mona Lisa, mas fica para outro dia).
Chegada a sua vez na fila, você colocava os cartões na leitora, apertava um botão, recolhia os cartões lidos e ia rezar na frente da impressora. Após alguns minutos, saia a sua impressão e você saia da sala para analisá-la.
Tratava-se, portanto de uma ambiente sem depuração interativa e com fortes restrições para o ciclo editar-compilar-executar. O resultado era pensar muito mais que codificadar. Na escola faziam-se coisas como o “teste de mesa”, simulando a execução do programa com papel e lápis. O deck de cartões era verificado à mão atrás de erros de sintaxe. Quando ocorria um erro, se procura entender direitinho as causas e verifica-se atentamente se o erro era repetido em outros pontos. Cada letra da impressão de saída era examinada atrás de pistas dos erros.
Embora o processo de desenvolvimento tenha melhorado muito com o passar dos anos nas minhas experiências fora da escola (estágio e posteriormente trabalho), restrições ainda estariam presentes por cerca de uma década. Por exemplo, em 1987 era comum usar um PC sem HD, usar um editor separado do compilador e depurar em assembler com o debug ou o symdeb.
Atualmente trabalhamos em ambientes integrados, que compilam programas em segundos (ou menos) e dispomos de depuradores altamente interativos. Se por um lado isto evita processos ineficientes (como a conferência manual de sintaxe), incentiva também um procedimento preguiçoso e a técnica de programação por tentativa e erro. Quantas vezes corrigimos apenas os primeiros erros de sintaxe indicados e mandamos recompilar ao invés de examinar os outros erros da lista? Quem nunca saiu testando alternativas ao invés de consultar uma documentação ou pensar um pouco? Quantos ainda rabiscam papel tentando conferir um algorítmo ao invés de ir andando passo a passo, corrigindo somente os erros com os quais topar?
Um pouco das técnicas passadas ainda me acompanham até hoje. Particularmente, tenho uma tendência a usar pouco depuradores. Entre outras coisas, é sempre divertido surpreender alguém apontando um erro no código somente olhando o fonte e o resultado. Alguns até acham isto mágica...
Assinar:
Postagens (Atom)