Pacotes

Uma das tarefas dos protocolos do nível de transporte, como o TCP, é garantir a entrega dos pacotes na ordem em que forem enviados. À primeira vista, isto parece desnecessário. Afinal, como os pacotes podem chegar no destino em ordem diferente da em que foram enviados? A resposta é que numa rede complexa existem vários caminhos entre a origem e o destino e nada obriga pacotes consecutivos a seguir o mesmo caminho.

Embora não tenha chegado ao extremo de chegar fora de ordem, meu último pedido na Amazom mostrou como pacotes consecutivos podem experimentar condições bem diferentes. Como mencionei antes, um dos livros foi enviando em um dia e o resto do pedido no dia seguinte. O livro que veio isolado estabeleceu um novo record, chegando em sete dias corridos. Já o resto do pedido chegou somente ontem (26 dias corridos, o que ainda é um prazo bom para o standard shipping).

Mudança do feed

Aviso aos assinantes (se é que tem algum): o Blogger mudou o endereço do feed para

http://dqsoft.blogspot.com/feeds/posts/full

Programando em C#

Embora eu já tenho obtido a certificação Microsoft em C#, não faz parte do meu dia-a-dia programar em C#. Normalmente programo em C, usando diretamente a API do Windows.

Surgiu agora uma "oportunidade" de mexer numa aplicação Windows em C# (na verdade, a necessidade de fazer os acertos finais em um projeto que eu estava coordenando e outro pessoa estava executando). Seguem algumas observações desta experiência.

Desempenho da IDE e da Aplicação

Um dos receios quanto ao Visual Studio e aplicações gerenciadas é quanto ao desempenho. A minha experiência até o momento foi boa, consigo desenvolver bem em um Pentium 4 2.8 HT, com 512M de Ram, mesmo com o Sql Server rodando na mesma máquina.

A Qualidade do Help

Minha impressão é que ao mesmo tempo que o Help do Visual Studio (MSDN Library) vem aumentado em tamanho (veio em DVD) a qualidade vem caindo. Eu fico lembrando toda hora da velha piada do piloto do helicoptero perdido que recebe a informação de que está... num helicóptero (informação tecnicamente correta e praticamente inútil).

A documentação está muitas vezes restrita ao tipo dos parâmetros (informação já apresentada pelo Intelisense). Alguns "exemplos" não fornecem muita coisa mais. Além disso, tem a mesma informação repetida na mesma página para VB.Net, C#, C++, J# e JScript.

Em comparação, a documentação da API do Windows contém muita informação sobre o quando usar, porque usar, etc.

Acessando Embedded Resources

Embedded Resources são informações, como textos e imagens, que são armazenadas dentro do próprio executável (mais precisamente, no Assembly .Net). No C + Windows API, o uso disto é quase sempre explícito. No .Net, a maior parte do tempo você não se preocupa com isto. Entretanto, se você precisar se preocupar, pode ter surpresas.

Basicamente o que eu precisei era acessar um ícone. Vou começar apresentando a solução:

1. Acrescente o arquivo com o ícone na solução (clique com o botão direito no nome do projeto, selecione Add Existing Item, navegue até o arquivo)
2. Selecione o arquivo e em Properties mude Build Action para Embedded Resource
   
3. No ponto em que você precisar do ícone coloque (supondo que o arquivo foi "Icone.ico")
   

Icon meuIcone = new Icon (GetType(), "Icone.ico")

Parece óbvio, afinal como eu posso ter errado isto? Bem, o help não tinha muita informação além de

public Icon (Type type, string resource);

e os exemplos que eu vi no livro Programming Microsoft Windows Forms e em alguns sites foram

Icon meuIcone = new Icon (GetType(), "Projeto.Icone.ico")

para confundir um pouco mais, embora a linha acima dê erro durante a execução (não acha o resource), se você examinar o Assembly com o MSIL Disassembler, vai ver que o ícone está lá e com o nome "Projeto.Icone.ico".

O que ocorre (e eu só achei no adendo do post de um blog) é que na hora de procurar o resource o namespace da classe do primeiro parâmetro é colocado automaticamente na frente do nome informado no segundo parâmetro. E o nome do resource no assembly é feito colocando o namespace default na frente do nome do arquivo. No meu caso, os namespaces eram os mesmos, e acabava sendo procurado Projeto.Projeto.Icone.ico ao invés de Projeto.Icone.ico.

Se você criar uma pasta no projeto para os seus ícones, por exemplo Icones, o nome do resource vai ficar Projeto.Icones.Icone.ico e portanto de ser usado

Icon meuIcone = new Icon (GetType(), "Icones.Icone.ico")

Depois que a gente entende, fica fácil...

Novo record da Amazon

No dia 30/8 (uma semana atrás) coloquei um pedido na Amazon. Entre os livros, um deles tinha data prevista de publicação 4/9; a minha grande preocupação era a Amazon não quebrar obrigatoriamente o pedido em dois, aumentando o custo do correio. Felizmente ela aceitou automaticamente o pedido de enviar tudo em uma única remessa, inclusive avisando que o despacho seria atrasado pelo livro que ainda não tinha saído.

Para minha surpresa, no dia seguinte (31/8) veio um email avisando que parte do pedido estava sendo mandado na frente (sem custo adicional): o livro ainda não lançado! O resto saiu no dia seguinte.

Hoje, 6/9, sete dias corridos após o pedido, o livro chegou! Não deu nem tempo de ficar com inveja dos fãs americanos que correram para comprar o livro na segunda feira. E olha que eu usei a opção mais barata de correio.

O único porém fica para o carteiro, que simplesmente largou a caixa na entrada; mesmo supondo que não tenhamos ouvido a campainha seria de esperar que ele fizesse questão de entregar em mãos a alguém.

Migração para Blogger Beta

Migrei o blog para o Bloger Beta para poder colocar labels nos post. Vamos torcer para não ter nenhum bug catastrófico!

Turbo Explorer

A Borland lançou ontem a linha Turbo, composta por versões Professional e Explorer do Turbo C++, Turbo Delphi, Turbo Delphi p/ .Net e Turbo C#.

As versões Explorer são gratuitas, download em:
http://www.borland.com/downloads/download_turbo.html

A PC Magazine já publicou um artigo sobre o Turbo Delphi Explorer. Apesar do preço (grátis) e de ser um produto bastante completo e atualizado, já existem algumas pessoas examinando os dentes do cavalo dado:

• Mesmo os produtos não .Net precisam ter o .Net Framework 1.1 instalado (para a IDE não para o executável gerado)
• É preciso ter o IE atualizado e o MSXML mais recente
• Só é possível instalar um produto Turbo Explorer na máquina; também não convive com o produto completo (Borland Developer Studio)
• Não vai ter versão Linux
• Os downloads são grandes

Lista: Nove Séries de Detetives

Para quem não viu ou não lembra, minhas regras para listas estão aqui. Neste caso, preferi listar os personagens e não livros específicos.

• Perry Mason: pouco conhecido aqui no Brasil, é um ícone nos EUA (pela proximidade geográfica, foi até mencionado no Chaves!). Perry Mason é o advogado detetive, que sempre tira um coelho da cartola nos capítulos finais, para desespero dos promotores e policiais que pensavam ter pegado o culpado. O autor (Erle Stanley Gardner) produziu dezenas de livros, o que complicou bastante o trabalho do meu pai de juntar todos eles (o que só conlcuiu com auxílio da Amazon).

• Hercule Poirot: o belga de cabeça de ovo criado por Agatha Christie. Embora eu tenha praticamente todos os livros, considero que eles se baseiam demais em truques da autora e não tem a mesma profundidade de outros desta lista. Um leitura divertida, de qualquer forma.
  

• Sherlock Holmes: criação de Conan Doyle é provavelmente o detetive mais conhecido do mundo, embora em desconfie que poucos leram os livros. Para quem ainda não leu, recomendo os que tem estórias curtas; os mais longos às vezes tem vários capítulos de romance não detetivesco (e talvez monótono)- vide a segunda parte de "Um Estudo em Vermelho". Nas histórias mais curtas brilham a inteligência do detetive e as situações fantásticas. Como os livros já estão no domínio público é fácil encontrar edições a preços baixos (quem preferir pode baixar do Projeto Gutemberg).

• Maigret: já escrevi sobre ele antes. Criação de Georges Simenon, as estórias normalmente culminam com a revelação de uma trama sórdida.

• Nero Wolfe: nas estórias escritas por Rex Stout, o caminho se sobrepõe ao destino. Embora exista um mistério, o que fascina é a interação entre os personagens. Nero Wolfe, nas suas próprias palavras, é apenas um gênio. Sua paixões são as orquídeas e a boa comida (aliás, ele pesa um sexto de tonelada). Para sustentá-las, resolve mistérios por preços altíssimos. Possui várias excentricidades, tornadas ainda mais fortes pelas excessões que ocasionalmente permite. É auxiliado por Archie Goodman, um detetive de porte mais tradicional, que tem entre as suas funções atormentar Wolfe para que ele trabalhe. Completam ainda o "cast" fixo o cozinheiro Fritz Brenner, os detetives free-lance Saul Panzer, Fred Durkin e Orrie Cather, a namorada de Archie (Lily Rowan e o inspetor de polícia Cramer.

• Philip Marlowe: imortalizado nas telas por Humphrey Bogart, o detetive criado por Raymond Chandler define (juntamente com Sam Spade do Falcão Maltês) e estilo noir. O detetive durão (mas de coração mole) faz piadas o tempo todo enquanto está perdido em meio a tramas complicadas e repletas de reviravoltas. Chandler possui um estilo todo especial de escrever, particularmente nas descrições e adjetivos. Pena que deixou tão poucos livros.

• Ellery Queen: já houve época em que este nome era sinônimo de mistério. Ellery Queen é ao mesmo tempo personagem (em alguns do dos livros) e autor (na verdade, era pseudônimo de dois primos, segredo este mantido por muito tempo). Suas histórias são bastante intensas e cheias de reviravoltas. Meus prediletos são os que tem Ellery também como personagem.

• Streeter: alguns anos atrás, procurando algo novo para ler, fui atraído pelas capas destes livros de Michel Stone, imitando os antigos pulps. São estórias no estilo noir porém ambientadas em tempos mais recentes e com techos muito criativos. Infelizmente os livros estão atualmente esgotados e parece que o autor parou após o quarto (eu só tenho dois deles).

• Inspector West: um detetive criado por John Creasey, com uma visão bem britânica. Destaco o livro A Gun for Inspector West, no qual o inspetor West se indigna com a sugestão de seus superiores de que ele passe a andar armado devido aos ataques de uma gangue violenta.
  

Livro do Mês Passado - Software Estimation

Steve McConnell é autor dos conhecidos livros Code Complete (que ainda não li) e Rapid Develpment (que li e recomendo).

Neste seu mais novo livro Software Estimation: Demystifying the Black Art (lançado agora em 2006) ele aborda a arte de estimar tamanho, esforço e prazo de projetos de software.

É um livro relativamente pequeno, cerca de 300 páginas, dividido em capítulos curtos, ideal para ler aos poucos. O livro é impresso em duas cores (preto e azul), o que é muito bem aproveitado nas tabelas, gráficos e figuras. Espero que a Microsoft Press utilize com mais frequência este tipo de recurso.

Além da experiência própria do autor (que fornece consultoria no assunto e desenvolveu um software para fazer estimativas), o livro utiliza uma quantidade imensa de dados reais coletados por diversos pesquisadores. Embora a maior parte das técnicas seja voltada para projetos de porte médio a grande, muito pode ser também aproveitado para projetos pequenos.

A utilidade deste livro não está limitada às pessoas cuja função é estimar software. O entendimento dos conceitos de estimativa pode reduzir o stress normalmente associado às estimativas e ao próprio desenvolvimento de software.

O livro está dividido em três partes:

• Conceitos Críticos
• Técnicas Fundamentais
• Desafios Específicos

Ao longo do livro são apresentadas 118 "dicas" (eu não contei, elas são reproduzidas em destaque no final do livro). Reproduzo algumas abaixo:

• Diferencie estimativas, alvos e compromissos. [Uma estimativa é um resultado obtido por uma avaliação, um alvo é um resultado desejado e um compromisso é um resultado acordado entre os envolvidos.]
• Quando uma estimativa é fornecida como um valor único (ao invés de uma faixa) existe implicitamente uma probabilidade associada.
• A penalidade para estimar para baixo é normalmente maior que estimar para cima. [Intuitivamente achamos que é o contrário]
• Existe um "Cone de Incerteza": á medida que um projeto avança, as estimativas podem ser mais precisas (desde que o projeto esteja sendo gerenciado adequadamente). [É tolice querer ser mais preciso que o estágio do projeto permite. Se o projeto não convergir, as estimativas não vão convergir - isto é um problema de gerenciamento e não de estimativa]
• Não dê estimativas de "bate-pronto". [Pensar um pouco, mesmo que alguns minutos, vai gerar uma estimativa mais precisa]
• O número de dígitos significativos e a unidade usada da estimativa deve ser compatível com a sua precisão. [Por exemplo, considere a diferença entre dizer 2 dias e dizer 16 horas]
• O tamanho do software é o fator mais significativo (mas não o único) na determinação do esforço e prazo.
• O esforço não cresce linearmente com o tamanho.
• As técnicas de estimativa devem ser escolhidas em função do que você quer estimar, o tamanho do projeto, o estágio do desenvolvimento, o estilo do desenvolvimento (interativo ou sequencial) e a precisão desejada.
• Contar quando possível. Se não for possível contar, calcular. Somente em último caso opinar. Não usar a opinião de especialistas para ajustar estimativas obtidas por cálculos.
• Guarde dados históricos dos projetos. A performance passada é o melhor indicador da performance futura. [Como otimistas, achamos sempre que os problemas anteriores não vão se repetir]
• Não discuta o resultado de uma estimativa [feita com método]. Mude o resultado somente alterando as entradas e recalculando.

Resumindo, altamente recomendado.

DVD: O Retângulo Negro

Esta semana comprei um filme em DVD e tive o maior susto quando fui assistir: de tempos em tempos (aleatoreamente) aparecia um retângulo preto no meio da tela, escondendo a maior parte da imagem.

Após experimentar todas as opções do aparelho de DVD, tentei com outro filme - e o problema continuou. Tentei o velho truque do "desce todo mundo/ sobe todo mundo" (reset geral - desligar da tomada, aguardar um tempo e ligar de novo) - e nada. Resolvi tentar ver o filme no micro: funcionou direitinho.

A cada tentativa o pânico aumentava. Cheguei a abrir o aparelho para ver se tinha algo de estranho (só o que o peso já indicava: tem quase nada dentro). Será que o filme (original!) tinha conseguido de alguma forma bagunçar o aparelho?

Como última opção (sem muita esperança) resolvi apelar para "São Google". Uma busca pelo meu modelo só trouxe anuncios e algumas procuras por senha para destravar a região. Por último, uma busca por "dvd black rectangle" e o santo fez o milagre:

http://club.cdfreaks.com/showthread.php?t=152593

Por incrível que pareça, o problema estava na TV: estava ligado um close caption estranho. Dois toques no controle da TV e tudo resolvido.

A volta do Turboman

Algum tempo atrás, comentando a decisão da Borland de sair do mercado de ambientes de desenvolvimento, eu ilustrei o post com um anúncio da Borland dos anos 80, usando o personagem Turboman. Para meu espanto, a Borland deu uma nova guinada e está ressucitando a linha Turbo e o Turboman.

Mas Que Diabos?

Nos últimos meses passei a acessar diariamente o site The Daily WTF (que traduzo candidamente como "O Mas Que Diabos Diário"). Este site traz relatos (supostamente todos reais) de coisas absurdas feitas por desenvolvedores.

Já vi uma razoável quantidade destas coisas (em situações absolutamente reais); não é incomum eu ficar resmungando quando estou dando manutenção ou tentando reaproveitar um pedaço de código. Por outro lado, não penso em enviar uma contribuição para o site. Acontece que quase todas as vezes eu conheci e convivi com o desenvolvedor responsável pelo WFT. Pessoas muito legais, esforçadas e que certamente não são idiotas.

Da mesma forma como relatado no site, os trechos ofensivos já tinham chegado nas mãos de clientes e muitas vezes já estavam em produção. O que traz a questão: porque estas coisas são feitas e porque demoram a ser detectadas?

Percebe-se sempre nos WTFs a falta do domínio de um conceito básico pelo desenvolvedor. Isto vem de diversas situações:

• O desenvolvedor está usando uma tecnologia que ele nunca estudou. O principal motivo é um otimismo tanto do desenvolvedor quanto do seu chefe de que a tecnologia será aprendida rapidamente, sem esforço e pelo simples uso. Muitas vezes o próprio desconhecimento da tecnologia impede de perceber que algo está sendo feito de errado (vide voodoo cargo cult).

• O desenvolvedor estudou a tecnologia mas não aprendeu. Fazendo um pegunta politicamente incorreta: será que qualquer um pode aprender a programar? É claro que é mais bonito pensar que todos podem fazer tudo, bastando estudo, prática e afinco. Entretanto, todos nós admitimos excessões em coisas como artes e esportes (ou alguém acha que qualquer um pode aprender a jogar como o Ronaldinho ou tocar guitarra como o Jimmy Page?). Será que aprender a programar exige alguma pré-disposição genética, com os neurônios interligados de uma certa forma? Eu certamente não sei a resposta. O fato é que existem muitas pessoas que estudaram programação, inclusive formalmente, atuam na área há anos e ainda tem falhas básicas de formação.

• O desenvolvedor abusou da abstração. Com freqüência se menciona a idéia de que rotinas, módulos e componentes devem ser usados como "caixas pretas", sem conhecimento do seu interior. Isto não significa que as suas características e limites não precisem ser bem conhecidos.

• Abuso do cut-and-paste (a rigor é a mesma coisa do item anterior). Cada vez mais, o desenvolvedor que não sabe algo faz uma busca na internet, à procura de código pronto (e não de uma explicação que permite ele mesmo escrever o código). É claro que a internet está cheia de besteiras. Mesmo que se ache algo correto, basta tirá-lo do contexto para causar desastres.

O passo seguinte é uma combinação perversa de garra, iniciativa e imaginação, que resulta nas mais absurdas soluções para o problema. Os WTFs são normalmente trechos longos e trabalhosos de código. Não se trata de pregiça mental ou braçal.

A questão seguinte é como esta pessoa foi alocada para um projeto para o qual não está preparada? A resposta é um excesso de otimismo generalizado, somado à dificuldade das pessoas em admitir suas limitações.

E como os WTFs não são detectados durante os desenvolvimentos?

Examinando apenas externamente, os softwares WTF funcionam pelo menos nas situações mais simples. Grande parte do esforço na geração dos WTFs vem justamente de martelar uma idéia errada até que o software consiga passar pelos testes. Frequentemente os testes são fracos e não existe muito rigor no processo de verificação. Muitas vezes o testador se concentra em um único aspecto e não tem nenhuma postura crítica com relação aos demais. Se os testes forem feitos pelo próprio desenvolvedor, estão contaminados desde o começo. Se os testes são feitos por outra pessoa, frequentemente ela se sente constrangida em relatar defeitos.

Uma forma mais efetiva seria a revisão de código. A maioria dos desenvolvedores se sente meio ultrajada em passar o código para outro verificar ("não confiam em mim"). Quem verifica pode não dar importância para tarefa ou se sentir constrangido em apontar defeitos.

A tudo isto soma-se uma falta de paciência (ou capacidade) do supervisor técnico para acompanhar os detalhes do desenvolvimento.

Uma vez chegando ao usuário, é comum uma certa complacência, baseada em padrões muito baixos ou mesmo a ausência deles. É comum ouvir coisas de usuários expressões como "é, isto nunca funcionou" ou "é lento mesmo" ou ainda "de vez enquando trava, mas fazendo de novo normalmente vai".

Em posts futuros vou tentar dar alguns conselhos para desenvolvedores sobre como evitar cirar WTFs.

Lista: Quatro Livros de Engenharia de Software

Para quem não viu ou não lembra, minhas regras para listas estão aqui.

Os livros listados abaixo discutem a atividade de desenvolvimento de software, apresentando filosofias, dicas e técnicas para ser um desenvolvedor melhor e mais feliz. Para ler e praticar!

• The Mythical Man Month, Fred Brooks - Escrito há três décadas, por uma pessoa que gerenciou o desenvolvimento de sistema operacional para mainframe (OS/360), muito deste livro continua se aplicando ao dia-a-dia do gerenciamento de desenvolvimento de software. Continua sendo verdade que ao se colocar mais pessoas em um projeto atrasado a tendência é o projeto atrasar mais e nenhuma metodologia ou ferramento é a bala mágica (silver bullet) capaz de reduzir esforçoes de uma ordem de grandeza (de anos para meses, por exemplo). Um livro mais conceitual, não atrelado a nenhuma linguagem ou ambiente.

• The Pragmatic Programmer, Andrew Hunt & David Thomas: Um livro repleto de filosofias e dicas práticas.

• The Practice of Programming, Brian Kernighan e Rob Pike: Mais voltado aos detalhes do desenvolvimento em si, contém dicas práticas para o desenvolvimento de software, com exemplos em C, C++ e Java.
  

• Rapid Development, Steve McConnel: Um tratado bastante completo sobre como evitar que um projeto vire um martírio. Muito bem organizado e recheado de estatísticas sobre projetos reais.

"CAPTCHA" nos comentário

Após a terceira visita de bots pelo blog, estou ligando esta chata opção. Vamos ver qual o resultado.

Lista: Sete Livros Juvenis

Existe uma estranha atração das pessoas por listas, tanto para ler como para escrever.

Este post traz a primeira do que pretendo ser várias listas. Adotei algumas regras para esta lista, que pretendo seguir nas próximas:

• Não parti de um número pré-definido de itens
• A lista não é dos melhores, maiores ou coisa parecida, é uma lista dos itens relevantes que me lembrei
• Não numerei nem ordenei os itens dentro da lista
• Coloquei apenas uma obra de cada autor. Alguns dos itens fazem parte de coleções (ou pelo menos são apenas uma dentre várias obras do autor que pertencem ao mesmo gênero).
• Não coloquei os tradicionais links para Amazon ou outras livrarias

Sete Livros Juvenis

Para os fins desta lista estou considerando "livro juvenil" um livro clássico (ou perto disso) que li quando estava no ginásio ou colégio.

• O Filho de Tarzan, Edgar Rice Burroughs: Os livros de Tarzan fizeram parte da minha infância, eu adorava lê-los no alto de uma árvore. Além dos exemplares que a minha mãe comprava, tinha também alguns volumes antigos de um primo do meu pai (ambos da mesma coleção, Terramarear). Minha mãe se desesperava com a possibilidade de eu aprender português errado por causa da ortografia nos livros antigos (perda de tempo, já que a ortografia mudou de novo pouco depois que eu me alfabetizei). Apesar dos recentes desenhos animados da Disney, as obras não estão disponíveis em português. Por outro lado, os primeiros livros em inglês já estão no dominio público e podem ser encontrados no Projeto Gutemberg.

• O Mistério da Ilha da Cabana, Franklin W Dixon: A coleção Hardy Boys é uma tradição americana. Conheci quando a Abril publicou no começo dos anos 70, no começo não gostei muito, mas no terceiro livro já estava viciado. Após o fim da publicação pela editora Abril (no volume 18), descobri que a coleção americana tinha mais de 50 livros, que fui comprando aos poucos (livro importado era difícl de achar e caro nos anos 70 e 80). Somente com a Internet fiquei sabendo como o Franklin W Dixon escreve livros de 1927 até os dias de hoje e o porque de alguns livros antigos (comprados em vendas de garagem) tinham o texto tão diferente. Aliás, quem se aventurar a comprar na Amazon tem a opção de comprar os livros com o texto original (publicados pela Applewood books).

• A Ilha Misteriosa, Jules Verne: Meu pai sempre foi um grande fã de Jules Verne. Por coincidência, o que considero o meu primeiro livro foi uma versão da Disney de 20000 Léguas Submarinas (convenci a minha mãe a comprar no supermercado, foi complicado pois não tinha preço e naquele tempo ainda não tinha computador nas lojas). Posteriormente meu pai comprava de tempos em tempos um volume de uma coleção portuguesa (para mais desespero da minha mãe). Embora os livros mais famosos do Jules Verne sejam Da Terra a Lua (que eu achei muito chato) e Viagem ao Centro da Terra (divertido), o meu predileto é A Ilha Misteriosa, com o relato de um bando de náufragos sobrevivendo em uma ilha com a ajuda da ciência e um benfeitor misterioso. Também disponível no Projeto Gutemberg.

• O Médico e o Monstro, R. L. Stevenson: Um dos primeiros livros que eu peguei na biblioteca do ginásio. Também disponível no Projeto Gutemberg.

• Um Estudo em Vermelho, Conan Doyle: O primeiro livro do Sherlock Homes. Outro que eu peguei na biblioteca do ginásio e também disponível no Projeto Gutemberg.

• Reinações de Narizinho, Monteiro Lobato: outra coleção que meu pai foi comprando aos poucos.

• As Minas do Rei Salomão, Rider Haggard: Este eu peguei emprestado na casa de um visinho, também estava com ortográfia muito antiga; minha mãe comprou correndo uma versão mais nova. Este exemplar sumiu, mas comprei alguns anos atrás um novo da coleção L&PM Pocket (que você acha até em bancas de jornal). Era a mesma tradução de Eça de Queiroz "que muito consideram superior ao original" (destaque na capa). Disponível no Projeto Gutemberg (o original, não a tradução).

Certificação Microsoft

Na minha opinião, os envolvidos com informática se dividem em dois grupos quando o assunto é certificação Microsoft. Existe uma minoria que tem experiência própria com isto e fala siglas estranhas como MCSE, MCAD, MCP e menciona o tempo todos números cabalísticos como 70-290 e 70-316. E existe a grande maioria que vive feliz ignorando tudo isto. O objetivo deste post é estragar a felicidade desde segundo grupo :)

As descrições abaixo podem conter erros ou ficarem desatualizadas, a página da Microsoft sobre certificação é www.microsoft.com/learning (pelo menos atualmente).

Como se obtem uma Certificação Microsoft

Com um exceção recente, as certificações Microsoft são obtidas passando em exames. Os exames são realizados em micros e, em grande parte, são compostos de questões de múltipla escolha. Não existe nenhum pré-requisito (curso, anos de experiência comprovada, etc); qualquer um pode fazer um exame e, se atingir a nota mínima, está aprovado.

Os exames são desenvolvidos pela Microsoft, porém a aplicação dos exames é feita por duas empresas americanas, a Pearson Vue e a Prometric. Estas empresas, por sua vez, credenciam centenas (milhares?) de centros de teste espalhados pelo globo. Atualmente os exames custam US$80, existem com frequência promoções envolvendo vales (vouchers) que cobrem parte ou todo o custo.

Ao passar no primeiro exame você se torna um MCP (Microsoft Certified Professional). Outros títulos são obtidos passando em combinações de provas.

O que você ganha sendo certificado

Fama, fortuna, mulheres lindas (ou homens lindos, se for o caso) - se você quer tudo isto é melhor tratar de aprender a jogar bola (ou a desfilar na passarela no cado das mulheres).

Para você mesmo, você poderá ganhar um pouco de auto-confiança. Para aquela minoria que conhece o assunto, você ganhará algum respeito pois eles sabem das dificuldades para obter uma certificação. O resto do mundo não vai saber exatamente do que se trata e, na sua maioria, vai ser indiferente.

A Microsoft envia um certificado, um broche e um cartão de identificação a cada certificação obtida (não a cada prova), mas você tem que solicitar. Você pode emoldurar o certificado e colocar sobre a mesa (no mínimo a assinatura impressa do Bill Gates vai chamar a atenção). Já experimentei usar o broche em eventos da Microsoft, ninguém prestou atenção. O cartão eu usei como fundo em uma das fotos deste blog (o primeiro uso prático que encontrei).

Nos eventos anuais da Microsoft é comum darem um brinde para os certificados.

Como se preparar para um exame

Ao contrário do que alguns imaginam, experiência profissional com a matéria de um exame não é condição necessária nem suficiente para passar. É perfeitamente possível estudar um assunto que não faça parte do seu dia-a-dia e passar no exame. No meu caso, uso os exames exatamente para me obrigar a estudar aquilo que não uso nem conheço. Por outro lado, uma característica dos exames é ser bastante abrangente enquanto que no trabalho a gente tende a se concentrar em uma faixa estreita.

Isto não significa que a experiência não seja útil, muito menos que o estudo não deva incluir uma parte prática.

Existem diversas formas de estudar para um exame, cada pessoa obtem melhores resultados com uma determinada combinação. As maneiras principais são cursos, livros, simulados e a prática.

Existem cursos voltados diretamente para a preparação aos exames e cursos mais gerais. Em algum ponto entre eles estão os cursos com material oficial da Microsoft (MOC - Microsoft Official Curriculum).

Da mesma forma, existem livros específicos para preparação, inclusive da Microsoft Press. Com uma exceção, usei sempre este tipo de livro como roteiro de estudo, complementando com informações obtidas na internet e livros sobre temas específicos (os bons livros de preparação costumam conter uma bibliografia no final de cada capítulo). Os livros de preparação se concentram na matéria que cai no exame e são bem resumidos, porém (pelo menos os bons) costumam conter também informações úteis para o dia-a-dia.

Várias empresas (como Transcender, ...) comercializam exames simulados, O custo destes simulados é relativamente alto; a única ocasião em que adquiri um foi para o meu primeiro exame de Análise de Requisitos e Definição de Arquiteturas, para me acostumar com o formato das questões. Felizmente as empresas costumam disponibilizar versões demo dos simulados (com poucas questões); vários livros de estudo vem com estas versões. Algumas empresas oferecem simulados com "questões reais de prova", existem questões legais e morais envolvidas (ver braindumps adiante).

Uma forma bastante eficiente de fixar o estudo é através da prática. Muitos livros de estudo contem exercícios práticos descritos passo a passo. Para fazer estes exercícios você vai precisar do produto, se não der para comprá-lo veja se não está disponível uma versão trial.

As Certificações de Desenvolvimento

Quando comecei a me interessar por certificação, a certificação para desenvolvedores era a MCSD (Microsoft Certified Software Developer), retroativamente chamada de MCSD Visual Studio 6. Para obter esta certificação eram necessários 4 exames: um de Análise de Requisitos e Definição de Arquiteturas, um de Desenvolvimento de Aplicação Desktop (com opções de Visual C++, Visual Basic e Visual FoxPro), um de Desenvolvimento de Aplicação Distribuida (também com opções de Visual C++, Visual Basic e Visual FoxPro) e um exame "eletivo" (escolhido livremente em uma lista de cerca de meia dúzia de exames). No meu caso fiz o exame de aplicação desktop para Visual C++, o de aplicação distribuida para Visual Basic e como eletivo o Projeto e Implementação de Base de dados com o SQL Server 2000.

Com o lançamento do .Net, a Microsoft criou duas novas certificações: MCAD (Microsoft Certified Application Developer) e MCSD .Net. Para ser um MCAD são precisos 3 exames: um exame de desenvolvimento de Web Services e Server Components (em C# ou VB.Net), um exame de Desenvolvimento de Aplicações (Windows ou Web, em C# ou VB.Net, num total de quatro opções) e um exame eletivo (com várias opções). Para ser um MCSD .Net são precisos 5 exames: um de Análise de Requisitos e Definição de Arquiteturas, um exame de Desenvolvimento de Web Services e Server Components (em C# ou VB.Net), um exame de Desenvolvimento de Aplicações Windows (em C# ou VB.Net), um exame de desenvolvimento de aplicações Web (em C# ou VB.Net) e um exame eletivo. No meu caso aproveitei o eletivo do MCSD VS6 e fiz os demais exames em C#. O lançamento do Visual Studio 2003 não afetou as certificações nem, até onde sei, os exames.

No final de 2005, junto com o lançamento do Visual Studio 2005, a Microsoft anunciou uma mudança profunda nas certificações. Foi criado o MCTS (Microsoft Certified Technology Specialist), com três credenciais para desenvolvedor, relativas a aplicações Web, Windows e Distribuídas. Cada uma destas credenciais requer apenas 2 exames, um igual para todas (Application Development Foundation) e outro específico. No início dos exames específicos deve-se escolher a linguagem de programação: C#, VB.Net ou C++ (somente para o exame de aplicações Windows). Além do MCTS, foi criado o Microsoft Certified Professional Developer: Enterprise Applications Developer. Para ser um MCPD:EAD é preciso passar nos 4 exames de MCTS e mais o exame Designing and Developing Enterprise Applications. Quem já é MCSD .Net pode obter o MCPD:EAD passando em dois exames de atualização.

Braindumps e Outras Robalheiras

Uma discussão sobre certificação não seria completa sem tocar neste assunto espinhoso (que muita gente prefere ignorar). No início de cada exame o candidato assina um termo de sigilo; a Microsoft protege as questões de prova também por copyright e como segredo industrial. Eventual material de rascunho usado durante a prova deve ser deixado no centro de teste.

Tudo isto não impede que algumas pessoas registrem em sites as suas recordações das questões de prova, gerando os chamados braindumps. Um outro candidato pode então decorar as perguntas e respostas e com isto passar no exame sem saber nada (supondo que o número de variações de perguntas seja baixo frente ao número de braindumpers).

Algumas pessoas são ainda mais preguiçosas e se limitam a falsificar o certificado (ou simplesmente colocar no currículo certificações que não possui).

Isto serve também de materia prima para espertalhões, que revendem os braindumps como material de estudo ou simulados ou até mesmo oferecem certificados falsos.

Como já disse em outra ocasião, tudo isto é imoral e ilegal.

19/out/07: pequenos acertos no texto.

Bugs Estranhos: INTERNAL COMPILER ERROR

O que você faz quando, ao corrigir o último erro de sintaxe em um programa C++, o Visual C++ v6 apresenta a mensagem

G:\Projetos\TOL\CColRF\CColRf.cpp(41) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'E:\8966\vc98\p2\src\P2\p2symtab.c', line 932)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information

E uma busca no google devolve um post em um forum de VB?

Felizmente o google achou uma resposta em lugar também improvável: uma lista de discussão do Samba.

Por incrível que parece, o problema todo é que estava compilando diretamente sobre a rede. Para resolver, bastou copiar tudo para uma unidade local.

E para quem está curioso, o VB utiliza (discretamente) o compilador do Visual C++ para gerar código executável.

Figurinhas e o Paradoxo dos Aniversários

Outro dia eu comprei alguns pacotes de figurinhas para a minha sobrinha e estávamos reclamando da quantidade de repetidas quando percebi que estava vendo uma manifestação do "paradoxo dos aniversários".

Para quem não conhece, este é um problema clássico de estatística: o professor pergunta para uma turma de 30 alunos se eles acham provável que pelo menos dois deles façam aniversário no mesmo dia. Os alunos acham que é improvável, o professor pergunta as datas de aniversário de cada um e, para surpresa dos alunos, encontra dois que fazem anversário no mesmo dia.

O "paradoxo" surge pelo fato de cada aluno pensar na probabilidade de algum dos outros fazer aniversário no mesmo dia que ele (29/365 = 8% *).

Este é daqueles problemas de estatística que se resolve mais facilmente calculando a probabilidade da negação. No caso, a probabilidade de 30 pessoas terem datas de aniversário distintas.

Para a primeira pessoa, a probabilidade é um. Para a segunda pessoa, a probabilidade é 364/365. Para a terceira pessoa é 363/365, múltiplicado pela probabilidade das duas anteriores não fazerem aniversário no mesmo dia (pois queremos que as duas coisas aconteçam simultaneamente), ou seja 364/365 * 363/365. Analogamente, para a quarta pessoa teremos (364*363*362)/(365*365*365). Para trinta pessoas o resultado é aproximadamente 0,29 (29%). Daí se conclui que a probabilidade de pelo menos duas pessoas em um grupo de 30 fazerem aniversário no mesmo dia é de 70%.

E as figurinhas? O album em questão tem 240 figurinhas e cada pacote vem com quatro. Isto resulta nas seguintes probabilidades de termos pelo menos uma figurinha repetida:

1 pacote = 2%
2 pacotes = 11%
3 pacotes = 24%
4 pacotes = 40%
5 pacotes = 55%
6 pacotes = 69%
7 pacotes = 80%
8 pacotes = 88%
9 pacotes = 93%
10 pacotes = 96%

Não é muito animador, certo?

* Estou desconsiderando o 29/fev. Fica como exercício para o leitor corrigir as probabilidades considerando os anos bissextos.

Dica Doméstica: Descongelamento

Quando a minha esposa vai no açogue costuma pedir para embalar a carne em separada em porções mais ou menos diárias. Ao chegar em casa vai tudo para o congelador.

Muito prático mas cria o problema de descongelar. Normalmente o que ela fazia era colocar em um prato fora da geladeira. Após várias hora ainda estava congelado e ela acabava apelando para o micro-ondas, o que acabava deixando as pontas cozidas.

Felizmente achei uma dica em um livro de culinária americano: coloque o produto a descongelar (fechado hermeticamente em um saco plástico, com o mínimo de ar possível) em uma vasilha grande com água a temperatura ambiente. Após algum tempo troque a água. Os resultados são excelentes.

Um comentário de engenheiro filho de físico: o segredo é que o ar é mau condutor de calor e a água é bom.

Yes, nós temos livrarias II: A Traça

Procurando na Internet informações sobre um livro obscuro que li quando criança, o Google retornou um link para A Traça.

É um simpátivo "sebo virtual" e a experiência de compra foi ótima: imediatamente após colocar o pedido (às 9:07) veio um e-mail confirmando o recebimento do pedido. Pouco depois (12:28) veio a informação de que o livro estava localizado e o débito no cartão tinha sido feito. No final da tarde (18:32), e-mail avisando que o livro tinha sido encaminhado ao correio. Na manhã seguinte (11:00) o Sedex estava sendo entregue. Detalhe: a Traça fica em Porto Alegre e aqui é São Paulo. O Correio foi tão rápido que o livro chegou antes do e-mail informando o identificador do objeto.

World eBook Fair - OnLine

Já está no ar o site do World eBook Fair, porém o acesso está bastante lento.

Em uma olhada rápida, já achei um livro curioso (que eu li anos atrás): Fallen Angels de Larry Niven, Jerry Pournelle e Michael Flynn. É uma sátira à onda anti-ciência que assola o mundo. Num futuro não muito distante, a raça humana se dividiu em dois grupos. A superfície da Terra é controlada por um governo "verde" totalitarista obrigando os que crêem na ciência a morar em estações espaciais. Dois destes astronautas caem na Terra e são salvos pela última resistência pró-tecnologia: os fãs de ficção científica. O livro é repleto de piadas e referências a episódios reais do mundo dos fãs. Uma leitura divertida, mas não para ser levada a sério.