terça-feira, março 31, 2009

Renovando Carta de Motorista em Osasco

Renovei recentemente a minha carteira de motorista e compartilho abaixo algumas dicas. Embora eu tenha renovado em Osasco, é provável que os procedimentos sejam semelhantes em outras cidades "pequenas". É bom lembrar que as regras podem ter mudado desde que eu fiz a renovação.

Osasco x São Paulo

A minha carteira tinha sido emitida em São Paulo. A tendência natural das pessoas é renovar na mesma cidade da emissão, mesmo que tenha mudado de residência (lembrando, é uma infração gravíssima fazer falsa declaração de domicílio para fins de registro, licenciamento ou habilitação - artigo 242 do Código Brasileiro de Trânsito).

Em uma cidade do porte de São Paulo, é bastante provável que você acabe se valendo de um despachante. Já em uma cidade menor, como Osasco, é plenamente viável você ir pessoalmente ao órgão de trânsito (Ciretran). E a taxa de transferência é muito inferior aos honorários do despachante.

O Procedimento

Existe uma certa flexibilidade na ordem de fazer as coisas. A ordem abaixo é a que segui. Infelizmente os horários não são muito "work-friendly", se prepare para negociar como o seu chefe uma flexibilizada de horários. Algumas tarefas burocráticas podem ser feitas por um parente, mas as regras para isto não são muito claras.

Você pode dirigir com a carteira vencida por até trinta dias. A informação que eu obtive é que você só pode iniciar o procedimento de renovação quinze dias antes da carta vencer, mas não senti muita firmeza sobre isto.

O Ciretran de Osasco realiza a prova de renovação uma vez por semana e ela é bastante concorrida. No meu caso, só consegui marcar a prova para a semana seguinte. A marcação da prova é feita preenchendo à mão um requerimento simples, é preciso apresentar a carteira de motorista que está vencendo e o RG.

Enquanto isto, tire uma foto 3x4 (só precisa de uma, mas o fotógrafo provavelmente não vai vender menos que quatro). Espero que você tenha sorte e consiga tirar uma boa foto.

Com a foto, RG, habilitação e um comprovante de residência (por enquanto os originais) vá fazer o exame médico. Existem uns poucos 'estabelecimentos' credenciados. O exame custou R$53,00 (tabelado) e não fugiu muito da expectativa deste tipo de exame obrigatório. O mais importante é que lá vão preencher o formulário oficial (RENACH). Confira atentamente o que está escrito. O médico tinha um horário de trabalho meio esquisito, uma ligação antes pode economizar uma visita à toa ou uma espera prolongada.

Agora é hora de estudar para a prova. O material você encontra no site do Denatran (http://www.denatran.gov.br/publicacoes/publicacao.asp):
  • Código de Trânsito Brasileiro - a parte mais importante é o capítulo XV (Das Infrações). Espere várias perguntas sobre o tipo de infração e a penalidade para diversos tipos de situações.
  • Noções de Primeiros Socorros no Trânsito
  • Direção Defensiva (este material parece ter sumido do site, mas você encontra procurando no Google)
No carro da minha irmã veio um livreto impresso com o conteúdo dos dois últimos documentos acima.

Na prova não caem perguntas sobre placas e sinalização (mas é bom você saber isto!).

O horário da prova era às 10:00 (10:00 am segundo o requerimento), com a recomendação de chegar 15 minutos antes. Se prepare para uma demora na entrada na sala (supondo que esteja cheia como a minha). As instruções falam para levar caneta e documento com foto legível (sic); embora eles não mencionem, leve a carteira de habilitação pois você precisa preencher o seu número de registro. A duração é uma hora, mas você deve precisar de muito menos que isto.

A prova tem 30 questões de múltipla alternativa, você precisa acertar pelo menos 21 (70%). Não considerei nenhuma delas como "pegadinha", mas tinha algumas com redação confusa e várias com lógica negada (marque a opção que não ...). O mais chato é que a prova tem o formato de uma folha dobrada e você precisa colocar as respostas na capa. Muita atenção ao copiar as respostas da parte de dentro para a capa, pois não são permitidas rasuras.

Os procedimentos tradicionais de prova se aplicam. Algumas sugestões:
  • Leia com muita atenção a pergunta e todas as opções (mesmo que você esteja certo que a resposta correta é uma das primeiras).
  • Em uma primeira passada, resolva somente as que você tiver certeza.
  • Dê uma respirada e conte quantas você já respondeu. Provavelmente você vai estar com 20 ou mais, o que dará a tranquilidade para enfrentar as questões mais difíceis.
  • Veja se o texto de alguma pergunta dá uma dica para a resposta de outra. É improvável, mas acontece.
  • Elimine as respostas que você tem certeza que estão erradas.
  • Se não tiver outra opção, chute. Não há distinção entre questões em branco e questões erradas.
O resultado sai na semana seguinte. Enquanto espera o resultado, pague a taxa. Apenas alguns poucos bancos aceitam o pagamento. Não tem uma guia para pagar, o caixa precisa conhecer o procedimento.

No dia de ver o resultado, leve xerox (não autenticado) do RG, CPF, CNH, comprovante de endereço e exame médico, mais o original do exame médico e o comprovante de pagamento da taxa. Se você passou, é só entregar tudo que a carteira deve sair no dia seguinte. A não ser que você seja mais uma vítima da...

Maldição da Carteira de Motorista

Há vários anos atrás, quando eu fui renovar a carteira estava entrando em vigor a carteira com foto. Eu tirei e entreguei a foto, mas estavam com "dificuldades técnicas". Após mais de um mês de espera o Detran entregou os pontos e me entregou uma carteira sem foto.

Na renovação seguinte estava em falta o papel especial.

Desta fez, foi uma atualização de sistema que paralisou a produção de carteiras. Resultado: três semanas de espera ao invés de um dia.


No geral acabei até me divertindo com a coisa. É preciso um pouco de paciência e um senso de humor meio doentio, mas foi muito menos traumático que se poderia imaginar.

31/12/09: correção de erros de digitação

segunda-feira, março 30, 2009

Jack Ganssle e Engenharia de Software

Na semana passada tive o prazer de assistir ao Workshop "Better Faster Firmware", promovido pela Tempo Real Eventos em conjunto com o Portal Embarcados. Embora a palestra fosse voltada para Sistemas Embarcados, e tivesse algumas partes bastante específicas de hardware e de software de baixo nível, grande parte da palestra se referiu a aspectos de Engenharia de Software que se aplicam a todo tipo de software.

Neste post vou comentar um pouco sobre o workshop e apresentar um resumo (muito simplificado) destes pontos mais genéricos.

Jack Ganssle

Não vou repetir aqui o currículo da fera, que você pode conferir aqui (em português) e aqui (em inglês). Basta dizer que tem muito tempo de experiência na área e hoje é um consultor que auxilia inclusive a NASA. Pessoalmente é um grande sujeito. Foi extremamente atencioso com todos, tanto durante o workshop como nos intervalos e no pequeno encontro no final.

O Workshop

A Tempo Real Eventos está de parabéns pela iniciativa de trazer um especialista estrangeiro, ainda mais para uma área não muito conhecida e badalada.

A crise infelizmente atrapalhou um pouco o evento e deve-se louvar também a coragem dos envolvidos em seguir em frente mesmo com um cenário adverso (ao custo de algumas pequenas economias secundárias). O custo do evento pode também ter assustado algumas pessoas, acostumadas com especialistas locais e/ou eventos subsidiados por fabricantes, mas estava dentro do que se pode esperar de um evento com um especialista estrangeiro de primeira grandeza.

O resultado foi uma sala não muito grande, com um pouco menos de 50 pessoas. Talvez alguém reclame que os coffee breaks não tinham muita variedade ou se arrependido de ter dito que entendia bem inglês (o que permitiu dispensar a tradução simultânea no evento), mas se tiver é uma minoria que estava silenciosa por lá. O que mais se escutava eram elogios e crença de que se seguirmos alguns dos ensinamentos vamos evitar muitos bugs em campo (o que representa um ganho imenso frente ao custo do workshop).

Engenharia de Software

O primeiro ponto mais genérico abordado é que as mudanças normalmente falham. Existem três abordagem possíveis para as mudanças: fazer nada, impor de cima para baixo ou criar de baixo para cima; apenas a última costuma dar resultados.

A estratégia básica para gerar produtos mais rapidamente consiste em usar boas idéias técnicas, inciar os testes no primeiro dia, gerenciar características para garantir prazo, detonar bugs agressivamente e criar um ambiente eficiente de desenvolvimento.

Uma coisa para tomar cuidado é com as medidas. Medidas podem ser usadas como motivadores, para gerar recompensas/punições e para entender o que está acontecendo. As duas primeiras aplicações costumam gerar distorções.

A qualidade é outra questão complicada. Todos querem, desde que seja de graça. É ela sai de graça para quem estiver disposta a investir pesado nela. Quem define o que é a qualidade é o cliente.

Todo mundo considera que reuso de código é bom, certo? Que tal então um slide avisando que reuso é veneno? O reuso requer uma vontade de reusar, um código bom e bem documentado e um código com poucas dependências. Antes de desenvolver um código para reuso, você precisa ter escrito este código pelo menos três vezes. E você só vai ter lucro a partir da terceira vez que reaproveitar o código.

Um fato conhecido é que o tempo de desenvolvimento aumenta de forma não linear com a complexidade do projeto. Um dos motivos disso é que um projeto maior requer mais pessoas, o que aumenta o tempo gasto na comunicação entre elas. A solução é particionar o código em pedaços pequenos com poucas dependências entre eles.

Um projeto possui metas técnicas, pessoais e de mercado. É preciso definir de forma honesta as prioridades entre estas metas, que acabam sendo conflitantes. É o famoso triângulo cronograma, qualidade e características - escolha duas.

Bugs são uma realidade da programação. Jack defende que os bugs devem ser resolvidos imediatamente, antes de se acrescentar código novo. A maioria dos bugs se concentram em poucos módulos - eles devem ser jogados fora e refeitos.

Além de funcionar um software deve comunicar a sua estrutura a outros projetistas. Para isto é fundamental a empresa ter um padrão de desenvolvimento (nomes, proibir variáveis globais, comentários, etc).

O programador deve gerenciar a complexidade (se depurar é duas vezes mais difícil que programar e você programa da forma mais 'esperta' que conseguir, o que vai acontecer?). Existe uma medida simples de complexidade, a complexidade ciclomática, que basicamente mede a quantidade de caminhos existentes dentro de uma rotina. Um código com complexidade ciclomática acima de 50 é considerado intestável de altíssimo risco.

Um método de reduzir bugs de forma eficiente é a Inspeção de Código, o que pressupõe existir um padrão de desenvolvimento. As inspeções não atrasam projetos, defeitos sim.

Uma segunda técnica para reduzir bugs é o Projeto Por Contrato, onde se explicita para cada rotina o que se espera das entradas (pré-condições), o que se promete para a saída (pós-condições) e o que será mantido (invariantes). Se você não é capaz de dizer exatamente o que uma rotina faz, é pouco provável que ela faça o que você espera.

O contrato pode ser garantido por teste adicionais no código. Na medida do possível, estes testes devem ser mantidos no código de produção - é a filosofia 'test what you flight, flight what you test' da NASA (isto é, os testes devem usar condições iguais à de produção e a produção deve rodar exatamente o código testado).

Na parte de metodologia, Jack recomenda o modelo evolucionário (também conhecido como espiral) e tem algumas boas restrições ao XP. Para estimar a duração, recomenda o método 'Wideband Delphi'.

Não esquecer que o código se deteriora com o tempo. É preciso investir periodicamente na limpeza do código (o que tem um custo linear), pois a deterioração tem um custo exponencial e rapidamente chega ao ponto em que o código tem que ser abandonado por não ser mais viável mantê-lo.

Em termos de ambiente de trabalho, existe um famoso estudo que mostra uma nítida correlação entre o ambiente de trabalho e a qualidade do código (Jack ficou abismado com ao saber que a maioria dos presentes trabalha em um ambiente aberto, não contando nem mesmo com um cubículo). Não esquecer também que tocar vários projetos simultaneamente reduz fortemente a produtividade.

Desastres

A última parte do workshop é a apresentação de uma sucessão de desastres, algum com custo de milhões de dólares e outros com custo de vidas. O padrão é claro:
  • teste insuficiente e em condições diferentes das reais
  • ausência de revisão de código
  • tratamentos de exceção inexistentes ou ridículos
  • pessoas cansadas cometem erros
  • nunca engane as ferramentas (como o sistema de controle de versão)
  • verifique valores antes de processá-los ou apresentá-los
O pior é que os erros são repetidos continuamente pelas mesmas pessoas. Daí a importância do postmortem: investigar no final do projeto o que deu certo e o que não deu.

sábado, março 21, 2009

Alberto Quadros (1963-2009)



O Beto era o filho do meio dentre cinco. Ao contrário dos seus irmãos mais velhos, sisudos e CDFs, ele era o mais esperto, mais divertido e mais feliz. Nem uma doença de "prognóstico terrível" conseguiu tirar o sorriso da foto ao lado.

Ele deixa uma esposa, um filho, um Jeep inacabado, um monte de amigos e muita, muita, saudade.

sexta-feira, março 20, 2009

O Protocolo YModem

O protocolo XModem que examinamos nos posts anteriores é voltado à transmissão dos dados de um arquivo de um computador para outro.

O protocolo YModem acrescenta um nível acima do XModem para permitir transferir informações sobre o arquivo, particularmente nome, tamanho e data. Isto possibilita:
  • Receber arquivos com tamanho arbitrário (no XModem o tamanho recebido é sempre múltiplo de 128 bytes).
  • Deixar a recepção mais automática, com o transmissor definindo o nome do arquivo.
  • Realizar a transferência de múltiplos arquivos (modo batch).
O YModem pressupõe a implementação do XModem com pacotes de 1K e CRC.

Uma transferência YModem se inicia da mesma forma que no XModem CRC, com o receptor enviando um caracter 'C' para indicar que está pronto. O transmissor, entretanto, responde com um pacote de número zero que contem as informações sobre o arquivo:
  • nome do arquivo, finalizado por um NUL (0x00)
  • tamanho do arquivo (opcional). O tamanho é transmitido em texto (ex: '1234'); o programa receptor deve desprezar os bytes irelevantes do último pacote recebido.
  • data do arquivo (opcional), separado por um espaço do tamanho. A data do arquivo é transmitida em octal como o número de segundos desde as zero horas GMT de primeiro de janeiro de 1970. A data zero indica que a data não é especificada.
  • outras informações menos usuais.
O receptor deve responder a um pacote zero correto com ACK e em seguida iniciar uma recepção normal XModem CRC, enviando novamente 'C'. A transferência dos dados do arquivo procede normalmente, exceto que o receptor não deve gravar os bytes que ultrapassem o tamanho informado.

Após enviar o ACK do EOT dos dados do arquivo, o receptor deve novamente enviar 'C' e aguardar um novo pacote zero. Um pacote zero com nome de arquivo vazio indica o fim dos arquivos.

Normalmente um programa transmissor YModem permite ao operador especificar uma máscara como nome de arquivo (como 'Arq*.txt'). O programa utiliza o protocolo para enviar todos os arquivos existentes que atendam à máscara. No programa receptor, o usuário apenas inicia a recepção, o programa recebe os arquivos e os salva com os nomes especificados.

Referência

XMODEM/YMODEM PROTOCOL REFERENCE
- Edited by Chuck Forsberg

quarta-feira, março 18, 2009

Aperfeiçoamentos do Protocolo XModem

No post anterior, vimos o XModem "básico". Este protocolo possui algumas limitações:
  • Não prevê como interromper uma transmissão
  • Utiliza caracteres simples (e portanto frágeis) para sinalizações
  • Possui um overhead alto (4 bytes de overhead para 128 bytes de dados)
  • Utiliza uma detecção de erros frágil (checksum)
  • Não informa o tamanho do arquivo
  • Não permite retomar uma transferência interrompida
Veremos aqui alguns aperfeiçoamentos que resolvem algumas destas limitações.

Interrupção da Transmissão

Uma convenção frequente é usar o caracter CAN (0x18) para solicitar a interrupção da transmissão. Quando suportado, o CAN é aceito pelo transmissor no lugar de ACK e NAK e no receptor no lugar de um pacote.

O suporte ao CAN agrava o próximo problema, o uso de caracteres isolados.

Uso de Caracteres Isolados

Idealmente, um protocolo deveria utilizar sempre pacotes para garantir que apenas comunicações validas são interpretadas. O XModem utiliza os seguintes caracteres isolados:
  • ACK: um ACK que for perdido ou danificado causará uma retransmissão, o que é perfeitamente aceitável. Se um ACK espúrio for recebido pelo transmissor isto causará uma dessincronização do número dos pacotes e consequente interrupção da transferência.
  • NAK: se um NAK for perdido ou danificado causará um timeout (salvo se for convertido em ACK). Um NAK espúrio recebido pelo transmissor causará uma retransmissão. Ambos os casos são perfeitamente aceitáveis.
  • EOT: se o EOT for perdido ou danificado ocorrerá uma retransmissão. Entretanto se um ACK espúrio for recebido pelo receptor ele considerará a transmissão encerrada com sucesso, o que é problemático. Para evitar isto, algumas implementações respondem com NAK ao primeiro EOT recebido e aguardam a sua retransmissão para confirmar o fim da transferência.
  • CAN (se usado): se um CAN for perdido ou danificado, a solicitação de interrupção não será bem sucedida. Se um CAN espúrio for recebido, a transferência será interrompida. Embora estas duas situações não sejam críticas elas são desagradáveis. Uma solução é enviar uma sequência de CANs e só interromper ao receber dois (ou mais) CANs consecutivos.
Overhead e XModem-1K

O pacote do XModem possui 132 bytes, dos quais 128 são de dados. Para reduzir o overhead existe o XModem-1K, que possui 1024 bytes de dados nos pacotes. Para distinguir os pacotes com 1024 bytes dos com 128, o byte inicial é substituído de SOH (0x01) para STX (0x02). O resto do protocolo é idêntico.

O receptor do XModem-1K deve estar preparado para receber pacotes dos dois tipos. Isto permite que o transmissor otimize o final da transferência, selecionando o tamanho mais apropriado para a quantidade de bytes a enviar.

XModem-CRC

O checksum usando no XModem é frágil. Intuitivamente, temos somente 256 valores possíveis para o checksum o que propicia acertar o checksum "por acaso".

O XModem-CRC substitui o checksum por um CRC de 16 bits, aumentando o tamanho do pacote de um byte. Explicar o funcionamento do CRC é uma tarefa longa (inclusive assunto de livros), porém basta considerar que não somente estamos falando de 65536 valores possíveis mas que o algorítmo garante a detecção de todos os erros de um ou dois bits no pacote.

O CRC utilizado é o chamado CRC CCITT, baseado no polinômio X^16 + X^12 + X^5 + 1. No pacote do XModem o CRC é transmitido com o byte mais significativo primeiro. Existem várias formas de calcular o CRC, há anos utilizo um método que dispensa o deslocamento bit-a-bit e o uso de tabelas, descrito no artigo The Great CRC Mystery de Terry Ritter, publicado na revista Dr Dobb's de Fevereiro de 1986.

O uso de CRC é uma iniciativa do receptor. Para isto ele transmite inicialmente o caracter 'C' ao invés de NAK. Para compatibilidade com o XModem Checksum, após algumas tentativas o receptor deve transmitir NAKs e utilizar checksum.

O uso de pacotes de 1K e do CRC são independentes. Entretanto, por motivos de confiabilidade não é recomendado usar pacotes de 1K com checksum.

O Tamanho do Arquivo

Uma vez que o XModem não informa o tamanho do arquivo e utiliza pacotes de tamanho fixo, o arquivo recebido tem sempre tamanho múltiplo de 128 bytes. Isto vem de uma característica do sistema CP/M-80 (onde o XModem foi inicialmente implementado).

Para resolver esta limitação e acrescentar algumas facilidades adicionais, foi criado o protocolo YModem, que é uma evolução direta do XModem e veremos no próximo post.

Retomada de Transferências.

Caso uma transferência XModem (ou YModem) seja interrompida, ela tem que ser recomeçada do seu início. Isto criava uma certa tensão ao ultrapassar a marca dos 70% na transferência de arquivos grandes (tensão esta que sobrevive nos tempos da internet devido ao não suporte universal para a retomada no protocolo FTP).

Isto viria a ser corrigido em outros protocolos, notadamente no ZModem. Entretanto, apesar do nome, o ZModem tem pouca semelhança com o XModem e é bastante complexo e provavelmente não vou abordá-lo nesta série de posts.

Referência

XMODEM/YMODEM PROTOCOL REFERENCE
- Edited by Chuck Forsberg

segunda-feira, março 16, 2009

O Protocolo XModem

O protocolo XModem é o pai de uma série de protocolos de transferência de arquivos que foram muito populares nos tempos da comunicação "banda magra" e que ainda são usados em dispositivos embarcados.

Já falei um pouco sobre ele antes (aqui e aqui) mas desta vez vou entrar em um pouco mais de detalhes.

A Vida On-Line Antes da Internet

A comunicação entre computadores via linha discada é algo bastante antigo. No mundo dos computadores pessoais, em 1978 (pouco depois do surgimento dos primeiros micros e muito antes de Tim Berners-Lee inventar a World Wide Web), Ward Christensen estabeleceu a primeira BBS.

Nos anos 80 um acessório cool era o modem. Inicialmente uma caixa externa e posteriormente uma placa de expansão, os modems da época permitiam comunicar via linha telefônica a velocidades como 300, 1200 e (mais tarde) 2400 bps (o que corresponde respectivamente a 30, 120 e 240 bytes por segundo).

Placa Listic TD1222/BV: 300, 1200, 1275 e 2400 bps!

As conexões eram bastante precárias. Não era incomum precisar algumas tentativas para os modems das duas pontas se entenderem. Conseguida a conexão, eram comuns três tipos de ocorrência:
  • a "geração espontânea" de caracteres, quando ruídos da linha eram errôneamente decodificados pelo modem;
  • o "sumiço" de caracteres, quando a comunicação entre as pontas era momentaneamente perdida; e
  • a alteração de caracteres em outros, devido à distorção do sinal.
E é claro que ocorriam também desconexões inesperadas.

O Protocolo XModem

Nas palavras de seu criador, o protocolo XModem surgiu de forma não planejada, para resolver um problema imediato de transferência de arquivos:

"It was a quick hack I threw together, very unplanned (like everything I do), to satisfy a personal need to communicate with 'some other' people"

O protocolo XModem supõe que exista um canal transparente entre os dois computadores, que permita o tráfego de qualquer byte de 0x00 a 0xFF. Alguns caracteres são utilizados pelo protocolo porém podem estar presentes dentro dos dados transferidos (o que é uma das vulnerabilidades do protocolo):

SOH 0x01
EOT 0x04
ACK 0x06
NAK 0x15

Na transferência de dados é utilizado um pacote com tamanho fixo de 132 bytes

onde
  • SOH (0x01) indica o início do pacote
  • PAC é o número do pacote. Este número começa com 1 e é incrementado a cada pacote. Após o pacotes 255 segue o pacote 0 (ou seja, o número do pacote é um byte que é incrementado ignorando o overflow);
  • ~PAC é o complemento de um do número do pacote. Pode ser calculado como 255-PAC ou invertendo cada bit
  • Dados são os dados transferidos, com tamanho fixo de 128 bytes.
  • CHK é o checksum, calculado somando todos os bytes de dados igonorando o overflow.
A dinâmica de comunicação é bastantes simples:
  • O receptor envia periodicamente NAK para indicar ao transmissor que está pronto para receber (isto permite disparar as pontas em qualquer ordem).
  • Ao escutar o NAK, o transmissor envia o primeiro pacote (de número 1)
  • Ao receber com sucesso um pacote, o receptor envia ACK. Se o pacote foi recebido incorretamente, envia NAK
  • Ao receber NAK o transmissor deve retransmitir o último pacote. Ao receber ACK o transmissor incrementa o número do pacote e envia o pacote seguinte (se existir)
  • Ao receber ACK do último pacotes, o transmissor envia EOT. O receptor deve confirmar o recebimento do EOT através de ACK.
A figura abaixo mostra esta dinâmica.


Considerações do Transmissor

O transmissor é bastante simples. O pacote a transmitir deve ser preferialmente montado antes do inicio da sua transmissão, para evitar pausas no meio da transmissão do pacote. Os momentos adequados para montar um pacote é no início da comunicação e após receber o ACK de um pacote. Antes de enviar o pacote (ou melhor ainda, antes de enviar o último caracter do pacote) o transmissor deve limpar a sua fila de recepção para diminuir a possibilidade de "lixo" ser interpretado como a resposta do receptor.

Embora costumeiramente o transmissor costume dar um timeout na resposta do receptor, isto não é obrigatório. Os timeouts no receptor são suficiente para recuperar as situações de erro.

Considerações do Receptor

Logo antes de enviar uma resposta o receptor deve limpar a sua fila de recepção, para diminuir a possibilidade de "lixo" ser interpretado. Na recepção do pacote, deve ignorar caracteres até receber a marca de início (SOH), dando timeout caso a marca não seja recebida dentro de um certo tempo. A partir deste ponto deve aguardar todos os caracteres do pacote, dando timeout caso o caracter seguinte não seja recebido dentro de 1 segundo. Em todos os casos de timeout o receptor deve enviar NAK.

Recebido um pacote, deve ser verificada a sua consistência, conferindo o número do pacote com seu complemento e o checksum dos dados. Se o pacote não estiver íntegro, o receptor deve enviar NAK.

Recebido um pacote íntegro, o receptor deve examinar o número do pacote:
  • Se for o pacote esperado, gravar os dados, incrementar o número do pacote esperado e enviar ACK.
  • Se for o pacote anterior ao esperado, enviar ACK. Isto ocorre se um ACK anterior foi extraviado ou danificado, causando a retransmissão do pacote.
  • Se for um pacote diferente do esperado ou o anterior, abortar a transferência. O transmissor e receptor perderam o sincronismo na numeração dos pacotes, possivelmente pelo transmissor achar que recebeu o ACK de um pacote que não foi recebido corretamente.
Concluindo

O protocolo XModem "básico" que foi apresentado é suficiente para muitas aplicações, principalmente as que envolvem conexões com baixas taxa de erro e volumes não elevados de dados. Ele possui, entretanto, algumas limitações. No próximo post da série vamos ver alguns aperfeiçoamentos populares para o XModem.

Referência

XMODEM/YMODEM PROTOCOL REFERENCE
- Edited by Chuck Forsberg

segunda-feira, março 09, 2009

Arapucas para o Desenvolvedor

O artigo Armadilhas para Desenvolvedores é muito bom, mas ao ler ao título eu imaginei algo um pouco diferente. O artigo trata de armadilhas de formação; neste post vou falar (principalmente por experiência própria) de algumas situações em que o desenvolvedor, por mais capacitado e experiente seja, acaba sendo atraído para grandes frias.

Daqui para frente, tudo vai ser diferente

Por mais encrencada que seja uma fase, sempre acreditamos que a fase seguinte vai correr tranquila. A partir de um certo ponto ficamos tão atraídos pela 'isca' do fim da fase atual que caímos desavisados nas encrencas da fase seguinte. Os piores projetos que eu conheci já davam sinais de dificuldade no pré-venda.

Nada como a experiência

A experiência pode ser uma coisa perigosa. Quando as coisas desandam de vez, o projeto vira a chamada 'death march' e todas as expectativas de lucro evaporam, a 'experiência' passa a ser o prêmio de consolação. Quem já não disse e ouviu a expressão "vale pela experiência"?

O problema está na hora de colocar esta experiência na prática. O mais comum é achar que a experiência irá neutralizar todas as dificuldades, ao invés de reconhecer que algumas delas são inerentes ao que estamos fazendo e apenas uma parte se deve a escolhas incorretas. Ocasionalmente ocorre o inverso: o trauma de um projeto ruim é tão grande que aquele tipo de problema passa a ser 'impossível'.

O limite da competência só é descoberto quando ele é ultrapassado

À medida em que conseguimos bons resultados, nos sentimos preparados para algo mais complexo. Até o momento em que passamos do limite da nossa competência. Para chefes, isto vale também na hora de delegar: você se entusiasma com o desempenho de uma pessoa e vai passando tarefas mais difíceis e um dia percebemos que passamos algo que ela não está conseguindo fazer.

Ferramentas

As arapucas relacionadas a ferramentas são fartamente conhecidas e documentadas. O que não impede de continuarem a fazer vítimas.
  • Quando se tem um martelo nas mãos, escondam as lâmpadas: A partir do momento em que se atinge a familiaridade com uma ferramente, particularmente uma linguagem de programação, usar uma outra fica cada vez menos confortável. E com isso vai-se usando a ferramenta em condições cada vez menos adequadas, até causar um desastre.
  • A atração da nova ferramenta: Paradoxalmente, existe também o efeito contrário, a atração do novo. Principalmente quando se trata de algo que está causando muito burburinho e que vai ficar bonito no currículo. Você sempre fez aplicações cliente servidor, todo mundo começa a falar em aplicações web - e você propõe que a próxima aplicação seja web, apesar de você e a empresa não terem nenhuma experiência nisso. Resultado, mais um projeto candidato ao prêmio de consolação.
  • Ferramentas miraculosas: A crença em milagres costuma ganhar do ceticismo. Muitos orçamentos e cronogramas se baseiam em obter resultados perfeitos de uma ferramenta com a qual temos pouca experiência.
O custo de voltar ao zero

Quando você se dá conta que pegou o caminho errado, você volta atrás ao último ponto conhecido, ou continua de forma meio aleatória na esperança de voltar logo à trilha? Eu pessoalmente costumo ir pela segunda opção e tenho a impressão que assim age a maioria. O motivo é o custo claro de voltar atrás contra a esperança de estar, pelo menos em parte, indo na direção correta.

É uma decisão complexa, mas desconfio que ninguém considera seriamente a opção de voltar ao zero quando as evidências mostram que foi tomada uma decisão incorreta (arquitetura, ferramenta ou mesmo projetista inadequado).

A Síndrome da Segunda Versão

É o complemento da arapuca anterior: após conseguir fazer com sucesso a primeira versão, se parte para um re-projeto total com a meta de colocar no sistema "tudo o que não deu para colocar no anterior". Isto transforma a segunda versão uma monstruosidade tão complexa que nunca consegue ser terminada.


Bem estas são as arapucas que eu consegui lembrar. Sintam-se livres para mencionar outras nos comentários.

sábado, março 07, 2009

Dando Ritmo ao Blog

Um dos meus problemas desde o começo foi garantir um fluxo razoavelmente constante de posts no blog. A situação melhorou bastante quando o Blogger passou a permitir agendar a publicação dos posts. Desta forma, nos momentos de maior inspiração e/ou tempo disponível dá para preparar os posts futuros e deixá-los engatilhados, para compensar os bloqueios e falta de tempo.

Nas boas fases, cheguei a ter uma semana (três a quatro posts) de buffer. Nas últimas semanas o agendamento é para a manhã seguinte (só para não perder a piada do Clube das 07:00).

E aí eu vou olhar no blog do Raymond Chen (The Old New Thing), de onde tirei o termo "Clube das 07:00" e ele revela o tamanho da fila dele. O post que foi publicado em 27/02/09 foi escrito em 13/02/08) . E ele deixa claro que não escreve posts no horário do expediente (e nem isto eu posso dizer).

Vamos ver se neste fim de semana eu consigo escrever alguns posts e voltar ao ritmo de pelo menos dois por semana.

domingo, março 01, 2009

Mas, Afinal, Sobre o Que É Este Blog?

Fui um dos sorteados na Promoção de Aniversário da Tecnofagia, e ganhei a publicação de um banner por um mês.


A preparação deste banner me levou a divagar sobre o que as pessoas encontram aqui: o que eu escrevo, como escrevo, etc.

Antes de Mais Nada...

Este é um espaço pessoal. Acimo de tudo, que escrevo o que eu quero escrever :)

Alguns blogs são bem focados em um tema, este não é o caso do DQSoft. Existem várias percepções sobre o que é um blog, tanto em termos de formato como de conteúdo; não me sinto preso a nenhuma delas.

O Formato dos Posts

Minha preferência é por posts de tamanho médio a longo, que contenham alguma contribuição minha. Somente muito ocasionalmente publico um post que contém apenas um link para um conteúdo alheio. Frequentemente me aventuro a falar sobre um assunto mais longo, que eu quebro em uma série de posts.

Muitos dos meus posts são baseados em experiências pessoais minhas, atuais ou antigas. Alguns posts são resultado de algo que aconteceu ou algo que li recentemente. De vez em quando me arrisco a escrever sobre algo que eu não conhecia. Em todos os casos (principalmente neste último) é comum eu fazer alguma pesquisa a respeito.

O Ritmo de Publicação

Varia bastante conforme o que acontece no meu trabalho e na minha vida pessoal. Neste último ano eu consegui aumentar a quantidade e a regularidade dos posts, particularmente depois que entrei para o Clube das 07:00.

Os Assuntos

A lista de categorias aí no lado dá uma idéia sobre o que escrevo.

O meu tema predileto é Programação, algo que pratico desde um pouco antes de ter acesso a um computador (cerca de três décadas atrás). Eu costumo falar sobre Engenharia de Software e Conceitos e Algorítmos Básicos. Ocasionalmente menciono alguma técnica específica em alguma linguagem.

Sou Engenheiro Eletrônico por formação, embora nunca tenha projetado Hardware profissionalmente. De vez em quando comento sobre um Processador que me interessou. As minhas atividades como hobbista tem envolvido principalmente Microcontroladores e existem aqui vários posts a respeito (e outros em preparação).

Sou viciado em leitura, e frequentemente coloco resenhas dos Livros que eu li, técnicos ou não. De vez em quando comento também um pouco sobre Música, DVDs e Histórias em Quadrinhos.

Não deixo de ser um usuário de softwares e hardwares, e as minhas experiências são relatadas aqui em Ferramentas, Acessórios e Vida Digital.

Estou envolvido principalmente com tecnologias da Microsoft, mas muito que falo sobre programação é independente de sistema operacional.

Escrevo um pouco sobre Jogos (por enquanto ainda nada sobre programação de jogos) mas reconheço que os meus gostos não são mainstream.

Algumas coisas antigas aparecem às vezes por aqui, mais por curiosidade que por relevância.

Como última categoria a descatar, de vez em quando escrevo sobre o próprio Blog. Como agora.