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.
domingo, julho 23, 2006
terça-feira, julho 11, 2006
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.
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.
segunda-feira, julho 10, 2006
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.
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.
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.
sexta-feira, julho 07, 2006
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.
É 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.
terça-feira, julho 04, 2006
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.
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.
quarta-feira, junho 28, 2006
World eBook Fair
Para quem não conhece, o Projeto Gutenberg reune textos que estão no domínio público (na sua maioria) e foram digitados por voluntários.
Comemorando o seu 35o (!) aniversário, está sendo organizado o World eBook Fair. De 4 de julho a 4 de agosto mais de 300.000 eBooks estarão disponíveis para download gratuito. Além dos eBooks do projeto Gutenberg (que já são e continuarão sendo gratuitos), outras editoras estarão disponibilizando obras, como a Baen Books. A previsão é repetir o evento nos próximos anos, aumentando a quantidade de obras a cada ano.
Comemorando o seu 35o (!) aniversário, está sendo organizado o World eBook Fair. De 4 de julho a 4 de agosto mais de 300.000 eBooks estarão disponíveis para download gratuito. Além dos eBooks do projeto Gutenberg (que já são e continuarão sendo gratuitos), outras editoras estarão disponibilizando obras, como a Baen Books. A previsão é repetir o evento nos próximos anos, aumentando a quantidade de obras a cada ano.
NCSD.Net - Oficialmente
Novamente demorou somente 2 dias para o resultado do exame chegar à Microsoft. Já solicitei o "Welcome Kit" (certificado, cartão e broche) .
segunda-feira, junho 26, 2006
MCSD.Net
Passei hoje na prova que faltava para ser um Microsoft Certified Software Developper for Microsoft .Net. A prova foi "Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET". Acabei não estudando muito devido ao curto tempo desde a prova anterior, um acúmulo de serviço e, principalmente, uma gripe irritante. Felizmente grande parte da matéria também fazia parte das provas anteriores. O resultado não foi brilhante, mas bem satisfatório (e mais que suficiente para a aprovação).
Próximos exames de certificação (upgrade para MCPD) só daqui a alguns meses. A família agradece...
Próximos exames de certificação (upgrade para MCPD) só daqui a alguns meses. A família agradece...
quarta-feira, junho 07, 2006
MCAD - Oficialmente
Desta vez as coisas funcionaram rápido e o resultado do exame que eu fiz dois dias atrás já chegou na Microsoft (teoricamente poderia demorar até duas semanas e no exame anterior demorou três).
Agora só falta receber o diploma pelo correio.
Agora só falta receber o diploma pelo correio.
terça-feira, junho 06, 2006
C# x VB.Net
Estou estudando para a prova de desenvolvimento de aplicações Windows pelo Self-Paced Training Kit da Microsoft, primeira edição. Não é um bom livro (mais sobre isto adiante), mas tem a curiosidade de abordar simultaneamente C# e VB.Net.
É claro que a maior parte de programação .Net consiste em usar as classes do .Net Framework, que são as mesmas para as duas linguagens. Entretanto, mesmo as construções normais das linguagens são quase idênticas, recursos que existem somente em uma delas são raras excessões. A diferença fica na somente sintaxe. Dada a minha vivência com C, não é surpresa que eu ache a sintaxe do VB.Net esquisita, particularmente o uso do fim de linha como terminador de comando.
O mais curioso foi que recentemente perguntei a um desenvolvedor que usa o VB.Net no dia a dia porque ele preferiu VB .Net a C# e a resposta foi que o C# oferece mais controle, sendo mais adequado para o desenvolvemento de componentes, porém o VB.Net tem maior produtividade, permitindo fazer mais coisas com menos linhas de código. Acredito que seja a manifestação de um efeito relatado no clássico The Hidden Persuaders, um livro da década de 50 sobre o marketing científico. Um fabricante de sabão em pó colocou o mesmo produto em duas embalagens, uma em suaves tons de azul e outra em um violento vermelho, e entregou para várias donas de casa testarem. Ao final do teste, quem recebeu a caixa azul disse que o produto era excelente, porém não tinha força suficiente para tirar as manchas mais pesadas. Já quem recebeu a caixa vermelha disse que o produto excelente, mas que não devia ser usado com roupas frágeis pois era muito forte!
Voltando ao livro, ele possui uma grande quantidade de erros de revisão, principalmente nos exemplos. Mais preocupante, encontrei um erro grave: na descrição de propriedades, o livro afirma que uma propriedade read-only precisa obrigatoriamente estar associada a um campo readonly da classe (no C# e VB .Net um campo readonly pode ser iniciado apenas na declaração ou no construtor da classe). Em primeiro lugar, é possível ter uma propriedade read-only que dá acesso de apenas leitura a um campo não readonly. Mais importante, uma propriedade não precisa estar associada a um campo. Uma propriedade é uma abstração que cria um membro que se comporta como um campo independente da forma como é implementado internamente.
Para quem tiver a curiosidade de saber porque comprei este livro, foi logo após o lançamento do Visual Studio .Net, em junho de 2002. Neste época existia pouca oferta de livros sobre C# e a descrição do livro é bastante interessante. O problema todo é na implementação...
21/jun/06: acertados alguns erros de digitação.
É claro que a maior parte de programação .Net consiste em usar as classes do .Net Framework, que são as mesmas para as duas linguagens. Entretanto, mesmo as construções normais das linguagens são quase idênticas, recursos que existem somente em uma delas são raras excessões. A diferença fica na somente sintaxe. Dada a minha vivência com C, não é surpresa que eu ache a sintaxe do VB.Net esquisita, particularmente o uso do fim de linha como terminador de comando.
O mais curioso foi que recentemente perguntei a um desenvolvedor que usa o VB.Net no dia a dia porque ele preferiu VB .Net a C# e a resposta foi que o C# oferece mais controle, sendo mais adequado para o desenvolvemento de componentes, porém o VB.Net tem maior produtividade, permitindo fazer mais coisas com menos linhas de código. Acredito que seja a manifestação de um efeito relatado no clássico The Hidden Persuaders, um livro da década de 50 sobre o marketing científico. Um fabricante de sabão em pó colocou o mesmo produto em duas embalagens, uma em suaves tons de azul e outra em um violento vermelho, e entregou para várias donas de casa testarem. Ao final do teste, quem recebeu a caixa azul disse que o produto era excelente, porém não tinha força suficiente para tirar as manchas mais pesadas. Já quem recebeu a caixa vermelha disse que o produto excelente, mas que não devia ser usado com roupas frágeis pois era muito forte!
Voltando ao livro, ele possui uma grande quantidade de erros de revisão, principalmente nos exemplos. Mais preocupante, encontrei um erro grave: na descrição de propriedades, o livro afirma que uma propriedade read-only precisa obrigatoriamente estar associada a um campo readonly da classe (no C# e VB .Net um campo readonly pode ser iniciado apenas na declaração ou no construtor da classe). Em primeiro lugar, é possível ter uma propriedade read-only que dá acesso de apenas leitura a um campo não readonly. Mais importante, uma propriedade não precisa estar associada a um campo. Uma propriedade é uma abstração que cria um membro que se comporta como um campo independente da forma como é implementado internamente.
Para quem tiver a curiosidade de saber porque comprei este livro, foi logo após o lançamento do Visual Studio .Net, em junho de 2002. Neste época existia pouca oferta de livros sobre C# e a descrição do livro é bastante interessante. O problema todo é na implementação...
21/jun/06: acertados alguns erros de digitação.
segunda-feira, junho 05, 2006
Desenvolvedor de Aplicativos Certificado Microsoft (MCAD)
Bem, ainda falta a minha nota chegar até a Microsoft (da última vez demorou algumas semanas e precisou de um cutucão), mas com a prova de hoje (exame 70-320 - Developing XML Web Services and Server Components with Microsoft Visual C#) completei os requisitos.
Eu estudei principalmente pelo Training Guide da Que, de autoria do Amit Kalani. O livro é muito bom, mas não deixa de ser um resumo. Cada um dos onze captítulos merece um livro a parte (e tenho quase certeza que existem todos estes livros). O livro contém uma quantidade generosa de exercícios práticos e vem com um CD com uma versão eletrônica do livro e um simulado demo (com 60 questões).
Eu estava muito confiante na vespera, tendo ido muito bem no simulado impresso do livro e razoavelmente bem no simulado do CD. No início da prova, como de costume, deu aquele susto de ver algumas coisas que eu nem sabia o que era... No final eu estava confiante de ter passado, mas por pouco. Nova surpresa ao ver o resultado: aparentemente a cultura geral e o bom senso (e provavelmente um pouco de sorte) funcionaram e um tirei um notão (devo ter errado somente três ou quatro questões das 43).
A principal dificuldade do exame é que ele cobre muita coisa e várias questões são sobre detalhes. Além disso, a redação das perguntas é muitas vezes confusa. Teve uma única questão que eu achei bastante fora do assunto (dizia respeito a uma propriedade de uma classe não relacionada diretamente a Web Services ou Server Components).
Bem, daqui a 3 semanas faço o último exame para obter a certificação MCSD .Net. Só para não esquecer, estas duas certificações já ficaram obsoletas com o lançamento do .Net Framework 2.0. No segundo semestre tento a sorte com os exames de upgrade.
Eu estudei principalmente pelo Training Guide da Que, de autoria do Amit Kalani. O livro é muito bom, mas não deixa de ser um resumo. Cada um dos onze captítulos merece um livro a parte (e tenho quase certeza que existem todos estes livros). O livro contém uma quantidade generosa de exercícios práticos e vem com um CD com uma versão eletrônica do livro e um simulado demo (com 60 questões).
Eu estava muito confiante na vespera, tendo ido muito bem no simulado impresso do livro e razoavelmente bem no simulado do CD. No início da prova, como de costume, deu aquele susto de ver algumas coisas que eu nem sabia o que era... No final eu estava confiante de ter passado, mas por pouco. Nova surpresa ao ver o resultado: aparentemente a cultura geral e o bom senso (e provavelmente um pouco de sorte) funcionaram e um tirei um notão (devo ter errado somente três ou quatro questões das 43).
A principal dificuldade do exame é que ele cobre muita coisa e várias questões são sobre detalhes. Além disso, a redação das perguntas é muitas vezes confusa. Teve uma única questão que eu achei bastante fora do assunto (dizia respeito a uma propriedade de uma classe não relacionada diretamente a Web Services ou Server Components).
Bem, daqui a 3 semanas faço o último exame para obter a certificação MCSD .Net. Só para não esquecer, estas duas certificações já ficaram obsoletas com o lançamento do .Net Framework 2.0. No segundo semestre tento a sorte com os exames de upgrade.
sexta-feira, maio 26, 2006
Sério ou Brincadeira?
Vi no Newsgroups do Technet o link abaixo
http://www.certifai.xpg.com.br/index.php
dei uma olhada no site e não consegui decidir se é ou não uma brincadeira. Será que alguém pagaria R$50 por um transcript MCP falso? (Para quem não conhece, o transcript MCP é uma folha com a relação das provas de certificação Microsoft que você fez, você imprime no seu próprio micro acessando um site da Microsoft).
Ah sim, é claro que ser for sério é ilegal, imoral, etc.
Agora vou voltar aos meus estudos para obter o meu certificado à moda antiga.
http://www.certifai.xpg.com.br/index.php
dei uma olhada no site e não consegui decidir se é ou não uma brincadeira. Será que alguém pagaria R$50 por um transcript MCP falso? (Para quem não conhece, o transcript MCP é uma folha com a relação das provas de certificação Microsoft que você fez, você imprime no seu próprio micro acessando um site da Microsoft).
Ah sim, é claro que ser for sério é ilegal, imoral, etc.
Agora vou voltar aos meus estudos para obter o meu certificado à moda antiga.
sexta-feira, maio 12, 2006
Certificação
Como mencionei em 10 de janeiro, estou a um exame da certificação MCAD e a dois exames da MCSD .Net (ambas já obsoletas). Graças às promoções do TechNet Brasil, tenho vouchers para exames gratuitos válidos até 1/julho. Portanto criei coragem e marquei o exame 70-320 para o começo de junho. Se sobrar fôlego, vou tentar também o 70-316.
Portanto, agora é "crunch time" e os posts aqui e no Wiki C/C++ Brasil vão ficar ainda mais escassos.
Portanto, agora é "crunch time" e os posts aqui e no Wiki C/C++ Brasil vão ficar ainda mais escassos.
sexta-feira, maio 05, 2006
sexta-feira, abril 28, 2006
Bugs Terríveis de Achar - Execução Paranormal de Código
Os dois últimos dias foram de uma busca frenética atrás de um bug.
O bug se apresentou em um firmware que estamos desenvolvendo para um dispositivo e que roda em um microcontrolador. A programação deste tipo (sistema embarcado) é bem diferente da programação normal para PC. Como é comum nestes casos, o firmware é gravado em uma memória não volátil (memória Flash) dentro do próprio microcontrolador. Esta gravação é feita por um software de PC, através de um gravador ligado à porta paralela do PC e a determinados pinos do microcontrolador.
Uma segunda memória não volátil (EEProm), externa ao microcontrolador, é usada para manter dados não voláteis, alguns deles extremamente críticos para a operação (como o número de série do dispositivo). A gravação na EEProm requer uma série de passos: é preciso habilitar a gravação, enviar o comando de gravação, o endereço e o dado. Não é algo que possa acontecer por conta própria.
No processo de produção dos dispositivos, é gravado primeiro um software de teste no microcontrolador. Através de uma serial de debug, são feitos testes e gravadas as informações críticas. Após isto é gravado o firmware normal.
Bem, após a produção de 140 dispositivos, verificou-se que cerca de uma dúzia estava com número de série incorreto. Pânico! Uma primeira hipótese, erro de operação na produção, parece improvável dado a taxa de erros. Restam o software de teste estar gravando algo errado ou, pânico maior, o firmware normal estar destruindo as informações na EEProm. Por outro lado, este efeito nunca tinha sido observado com as duas dezenas de protótipos.
Uma primeira revisão do firmware mostra que a EEProm é gravada em poucos pontos. Segue-se uma discussão filosófica sobre a necessidade e conveniência destes pontos. Faz sentido colocar um número de série default em caso erro de checksum na EEProm? A conclusão é que o firmware normal deve evitar ao máximo gravar na região onde estão os parâmetros mais críticos. Entretanto, mudar isto antes de descobrir o que está acontecendo pode apenas mascarar um problema sério.
A decisão é acrescentar um teste para tentar pegar se o número de série está danificado. Se sim, acender um LED de erro e preservar o conteúdo da EEProm para ver se dá uma pista do que ocorre. Em seguida, tentar reproduzir o problema, refazendo o procedimento de produção com esta nova versão.
Feito o procedimento com 20 dispositivos, em 2 ocorre o erro. É uma boa notícia: o problema pode ser reproduzido.
Alguns testes mostram que o software de teste está gravando os valores corretos na EEProm. Hora de ativar os traces do firmware e observar as informações enviadas pela serial. Após alguma tentativas, verifica-se que a corrupção da EEProm ocorre logo após a carga do firmware.
O teste começa a ficar mais complicado. É preciso prestar atenção no trace enviado pelo dispositivo quando ele é re-iniciado após a carga. É um problema esporádico, às vezes ocorre apenas após muitas tentativas. Para dificultar, às vezes ocorre um erro na verificação feita após a gravação. Outras vezes, a execução do firmware não acontece ao final da gravação e verificação, sendo preciso esticar o braço e desligar e re-ligar o dispositivo.
Prestando mais atenção, percebe-se que o firmware executa mesmo quando ocorre um erro na verificação. Em uma destas ocasiões, o conteúdo da EEProm é danificado. Primeira teoria: o firmware executado estava danificado de uma forma que causou a gravação incorreta da EEProm. Segue-se uma discussão de como o firmware pode descobrir que está gravado errado e não executar neste caso (a técnica tradicional é colocar um checkum no código, obviamente não resolve se a rotina de verificação estiver danificada).
Segue-se mais bateria de testes, tentando ver se sempre que a EEProm é danificada ocorreu erro na verificação. Alguns minutos depois, teoria abalada: a EEprom foi corrompida sem que tivesse ocorrido erro de verificação.
Para tentar cercar mais o problema, coloquei na rotina de gravação da EEProm (no mais baixo nível) um teste do endereço de gravação. Se for o endereço do número de série, ao invés de gravar envia um ! para a serial. Mais algumas tentativas e aparece !!! isolado, sem os demais traces...
Olhando com mais atenção ainda, percebemos que existe alguma atividade no dispositivo durante a verificação da gravação, quando o processador devia estar parado. Nova teoria: existe algo errado no processo de gravação e verificação, que faz o processador iniciar a execução antes da hora e de forma "meio torta".
Para comprovar, coloquei uma variável que é iniciada com zero e incrementada a cada passo da iniciação do software. Na rotina de escrita na EEProm, acrescentei um teste: se não tiverem sido executados todos os passos da iniciação, envia pela serial @ seguido do valor do contador. Alguns poucos testes são suficientes para ver alguns @0 e @1 surgirem durante a verificação. Execução paranormal: a rotina de gravação está sendo executada desrespeitando o fluxo normal da execução.
Hora de reclamar do gravador para o projetista do hardware. Aparentemente o processador está recebendo um sinal de reset fora de hora. Após algumas tentativas de achar uma explicação no software para o comportamento anormal, decide-se colocar um capacitorzinho no sinal de reset que vem do gravador (algo como dar um tempinho em software). Antes de soldar o capacitor, o técnico decidiu verificar o cabo. Tinha um mau contato no pino de reset. Testes com um outro cabo e com o cabo com o mau contato eliminado confirmam que o problema sumiu.
Resumindo, um mau contato no cabo usado para gravar o firmware fazia com que ocasionalmente o sinal de reset "balança-se" durante a verificação da gravação. Isto deixava o processador meio "bêbado" e ele saia executando errado o firmware.
Agora é só eliminar todos os problemas potenciais que identificamos enquanto procurávamos o bug que não existia.
O bug se apresentou em um firmware que estamos desenvolvendo para um dispositivo e que roda em um microcontrolador. A programação deste tipo (sistema embarcado) é bem diferente da programação normal para PC. Como é comum nestes casos, o firmware é gravado em uma memória não volátil (memória Flash) dentro do próprio microcontrolador. Esta gravação é feita por um software de PC, através de um gravador ligado à porta paralela do PC e a determinados pinos do microcontrolador.
Uma segunda memória não volátil (EEProm), externa ao microcontrolador, é usada para manter dados não voláteis, alguns deles extremamente críticos para a operação (como o número de série do dispositivo). A gravação na EEProm requer uma série de passos: é preciso habilitar a gravação, enviar o comando de gravação, o endereço e o dado. Não é algo que possa acontecer por conta própria.
No processo de produção dos dispositivos, é gravado primeiro um software de teste no microcontrolador. Através de uma serial de debug, são feitos testes e gravadas as informações críticas. Após isto é gravado o firmware normal.
Bem, após a produção de 140 dispositivos, verificou-se que cerca de uma dúzia estava com número de série incorreto. Pânico! Uma primeira hipótese, erro de operação na produção, parece improvável dado a taxa de erros. Restam o software de teste estar gravando algo errado ou, pânico maior, o firmware normal estar destruindo as informações na EEProm. Por outro lado, este efeito nunca tinha sido observado com as duas dezenas de protótipos.
Uma primeira revisão do firmware mostra que a EEProm é gravada em poucos pontos. Segue-se uma discussão filosófica sobre a necessidade e conveniência destes pontos. Faz sentido colocar um número de série default em caso erro de checksum na EEProm? A conclusão é que o firmware normal deve evitar ao máximo gravar na região onde estão os parâmetros mais críticos. Entretanto, mudar isto antes de descobrir o que está acontecendo pode apenas mascarar um problema sério.
A decisão é acrescentar um teste para tentar pegar se o número de série está danificado. Se sim, acender um LED de erro e preservar o conteúdo da EEProm para ver se dá uma pista do que ocorre. Em seguida, tentar reproduzir o problema, refazendo o procedimento de produção com esta nova versão.
Feito o procedimento com 20 dispositivos, em 2 ocorre o erro. É uma boa notícia: o problema pode ser reproduzido.
Alguns testes mostram que o software de teste está gravando os valores corretos na EEProm. Hora de ativar os traces do firmware e observar as informações enviadas pela serial. Após alguma tentativas, verifica-se que a corrupção da EEProm ocorre logo após a carga do firmware.
O teste começa a ficar mais complicado. É preciso prestar atenção no trace enviado pelo dispositivo quando ele é re-iniciado após a carga. É um problema esporádico, às vezes ocorre apenas após muitas tentativas. Para dificultar, às vezes ocorre um erro na verificação feita após a gravação. Outras vezes, a execução do firmware não acontece ao final da gravação e verificação, sendo preciso esticar o braço e desligar e re-ligar o dispositivo.
Prestando mais atenção, percebe-se que o firmware executa mesmo quando ocorre um erro na verificação. Em uma destas ocasiões, o conteúdo da EEProm é danificado. Primeira teoria: o firmware executado estava danificado de uma forma que causou a gravação incorreta da EEProm. Segue-se uma discussão de como o firmware pode descobrir que está gravado errado e não executar neste caso (a técnica tradicional é colocar um checkum no código, obviamente não resolve se a rotina de verificação estiver danificada).
Segue-se mais bateria de testes, tentando ver se sempre que a EEProm é danificada ocorreu erro na verificação. Alguns minutos depois, teoria abalada: a EEprom foi corrompida sem que tivesse ocorrido erro de verificação.
Para tentar cercar mais o problema, coloquei na rotina de gravação da EEProm (no mais baixo nível) um teste do endereço de gravação. Se for o endereço do número de série, ao invés de gravar envia um ! para a serial. Mais algumas tentativas e aparece !!! isolado, sem os demais traces...
Olhando com mais atenção ainda, percebemos que existe alguma atividade no dispositivo durante a verificação da gravação, quando o processador devia estar parado. Nova teoria: existe algo errado no processo de gravação e verificação, que faz o processador iniciar a execução antes da hora e de forma "meio torta".
Para comprovar, coloquei uma variável que é iniciada com zero e incrementada a cada passo da iniciação do software. Na rotina de escrita na EEProm, acrescentei um teste: se não tiverem sido executados todos os passos da iniciação, envia pela serial @ seguido do valor do contador. Alguns poucos testes são suficientes para ver alguns @0 e @1 surgirem durante a verificação. Execução paranormal: a rotina de gravação está sendo executada desrespeitando o fluxo normal da execução.
Hora de reclamar do gravador para o projetista do hardware. Aparentemente o processador está recebendo um sinal de reset fora de hora. Após algumas tentativas de achar uma explicação no software para o comportamento anormal, decide-se colocar um capacitorzinho no sinal de reset que vem do gravador (algo como dar um tempinho em software). Antes de soldar o capacitor, o técnico decidiu verificar o cabo. Tinha um mau contato no pino de reset. Testes com um outro cabo e com o cabo com o mau contato eliminado confirmam que o problema sumiu.
Resumindo, um mau contato no cabo usado para gravar o firmware fazia com que ocasionalmente o sinal de reset "balança-se" durante a verificação da gravação. Isto deixava o processador meio "bêbado" e ele saia executando errado o firmware.
Agora é só eliminar todos os problemas potenciais que identificamos enquanto procurávamos o bug que não existia.
quinta-feira, abril 20, 2006
Sinais de Um Programa Ruim
Esbarrei com um artigo interessante sobre sinais no código fonte que indicam um programa problemático. Para quem não tiver paciência de ler o artigo todo, eis a lista de sinais:
Se você precisar dar manutenção em um software, verifique antes os sinais. Se forem muitos, considere seriamente fazer um refactoring (mas pense muito antes de reescrever tudo).
- Comentários ausentes ou ruins
- Nomes inapropriados
- Formatação inconsistente do fonte
- Falta de teste de códigos de retorno e de erros em geral
- Repetições de código
- Falta de clareza
- Complicações desnecessárias
- Condições assumidas não documentadas
- Substituição das funções das bibliotecas padrões por funções próprias
- Falta de suporte à depuração
Se você precisar dar manutenção em um software, verifique antes os sinais. Se forem muitos, considere seriamente fazer um refactoring (mas pense muito antes de reescrever tudo).
quarta-feira, abril 19, 2006
GPF - Grilo Pulsante Fantasma
A foto acima é do brinqedinho que levei no Segundo Encontro de Programadores C/C++ em São Paulo. Como a regua e o cartão mostram, é um circuito bastante pequeno, onde os maiores componentes são a bateria, o buzzer (uma espécie de alto falante sem imã) e o resistor sensível a luz (LDR).O componente mais importante, entretanto, é o PIC 12F675. Trata-se de um microcontrolador, um computardor quase completo dentro de um chip. Este modelo possui 1024 palavras para armazenamento de programa (Flash), 64 bytes de Ram para variáveis e 128 bytes de memória não volátil para dados (EEProm). O processador utiliza um conjunto de apenas 35 instruções. Neste projeto usei o clock interno de 4 MHz, o componente permite usar um cristal externo de até 20MHz. Possui um modo sleep, útil a circuitos a bateria, que reduz o consumo de energia a quase zero.
O microcontrolador possui uma quantidade grande de recursos. Possui internamente dois timers, que podem ser usados para gerar interrupções periódicas, fornecendo uma base tempo para o software. Seis dos oito pinos podem ser tratados como entrada ou saída digital (isto é, serem colocados em nível lógico "0" ou "1" por controle do software). Quatro dos pinos podem ser usados como entradas analógicas (o software pode ler o nível do sinal do pino como um valor digital de 8 ou 10 bits).
O objetivo do circuito era mostar os potenciais do microcontrolador e o fato dele poder até ser programado em C. Inspirado em um exemplo do fabricante do PIC, é um circuito para ser escondido em um lugar e perturbar as pessoas presentes. O circuito fica a maior parte do tempo dormindo. Em tempos aleatórios ele acorda e faz um pequeno bip (daí o grilo pulsante). Para tornar a detecção mais difícil, o bip é feito somente se o circuito estiver no escuro (daí o fantasma). O LED (que também só é acionado no escuro), permite confirmar que o circuito está ligado. Por último, um botão permite testar o circuito, soando o bip e piscando o LED. Desta forma, o cicuito usa:
- uma entrada digital (o botão)
- duas saídas digitais (o LED e o buzzer)
- uma entrada analógica (o sensor de luz)
- um timer para acordar o circuito periodicamente
- um timer para fornecer a temporização para a geração da frequência enviada ao buzzer.
O custo total do circuito fica abaixo de R$50. O PIC custa menos de R$15, comprado unitariamente em uma loja. O preço USA, para 100 peças é USD 1,19.
Quando se fala em microprocessadores, a maioria das pessoas pensa imediatamente em computadores de mesa. Entretanto a grande revolução está nos microcontroladores, que permitem acrescentar inteligência a equipamentos por um baixo custo. A nossa casa está repleta deles, escondidos em geladeiras, máquinas de lavar, micro-ondas, TVs, DVDs, etc.
segunda-feira, abril 17, 2006
Livros do mês
Um dos meus motivadores para aprender inglês foi a coleção de livros do meu pai, principalmente os de fição científica. A minha primeira leitura de verdade em inglês foi a trilogia original da Fundação de Isac Asimov (Foundation, Foundation and Empire e Second Foundation).
Embora isto tenho sido há muito tempo atrás, ainda existem alguns livros da coleção do meu pai que não tinha lido. Um deles era o clássico (infelizmente esgotado) The Weapon Shops of Isher de A. E. Van Vogt. Algumas idéias podem hoje parecer chavão, mas provavelmente eram novidade quando o livro foi escrito. É um daqueles livros que prende o leitor, você fica sempre querendo saber o que vai acontecer. De quebra tem um tradicional paradoxo de viagem no tempo, com o personagem que só existe no curto intervalo de tempo entre ele chegar do futuro e voltar ao passado.
Ao devolver este livro acabei pegando para reler The Double Helix de James D. Watson. São as recordações da descoberta da estrutura do DNA (que de forma não esperada esclareceu o processo de duplicação dos genes). O livro não se limita aos aspectos técnicos, tratando muito da questão do relacionamento entre os envolvidos e da concorrência versus cooperação. Mostra um pouco como funciona internamente o meio científico e as suas motivações.
Resumindo uma longa história em um único parágrafo, a estrutura do DNA foi descoberta por James Watson e Francis Crick após um período relativamente curto de estudos, a partir de dados experimentais (fotografias por raio-X de cristais de DNA) obtidos por Maurice Wilkins e Rosalind Franklin num trabalho bem mais demorado. Watson e Crick utilizaram principalmente a montagem de modelos, técnica usada anteriormente por Linus Pauling para descobrir a estrutura dos amino-ácidos e desprezada por Wilkins e Rosalind. Para complicar mais a situação, as principais fotografias usadas foram tiradas por Rosalind, e usadas sem o seu conhecimento, devido a problemas de relacionamento com os demais. Watson, Crick e Wilkins vieram ganhar o prêmio Nobel por esta descoberta (e outras relacionadas), porém Rosalind morreu alguns anos antes. Embora alguns considerem Rosalind uma injustiçada, prefiro a versão presente na Wikipedia.
Embora isto tenho sido há muito tempo atrás, ainda existem alguns livros da coleção do meu pai que não tinha lido. Um deles era o clássico (infelizmente esgotado) The Weapon Shops of Isher de A. E. Van Vogt. Algumas idéias podem hoje parecer chavão, mas provavelmente eram novidade quando o livro foi escrito. É um daqueles livros que prende o leitor, você fica sempre querendo saber o que vai acontecer. De quebra tem um tradicional paradoxo de viagem no tempo, com o personagem que só existe no curto intervalo de tempo entre ele chegar do futuro e voltar ao passado.
Ao devolver este livro acabei pegando para reler The Double Helix de James D. Watson. São as recordações da descoberta da estrutura do DNA (que de forma não esperada esclareceu o processo de duplicação dos genes). O livro não se limita aos aspectos técnicos, tratando muito da questão do relacionamento entre os envolvidos e da concorrência versus cooperação. Mostra um pouco como funciona internamente o meio científico e as suas motivações.
Resumindo uma longa história em um único parágrafo, a estrutura do DNA foi descoberta por James Watson e Francis Crick após um período relativamente curto de estudos, a partir de dados experimentais (fotografias por raio-X de cristais de DNA) obtidos por Maurice Wilkins e Rosalind Franklin num trabalho bem mais demorado. Watson e Crick utilizaram principalmente a montagem de modelos, técnica usada anteriormente por Linus Pauling para descobrir a estrutura dos amino-ácidos e desprezada por Wilkins e Rosalind. Para complicar mais a situação, as principais fotografias usadas foram tiradas por Rosalind, e usadas sem o seu conhecimento, devido a problemas de relacionamento com os demais. Watson, Crick e Wilkins vieram ganhar o prêmio Nobel por esta descoberta (e outras relacionadas), porém Rosalind morreu alguns anos antes. Embora alguns considerem Rosalind uma injustiçada, prefiro a versão presente na Wikipedia.
segunda-feira, abril 03, 2006
C e C++
No Wiki do "C/C++ Brasil" está em discussão o nome do grupo. Um ponto sempre lembrado é o desejo de manter o C no nome, e nesta hora me sinto meio culpado, já que às vezes sinto que sou o único do grupo que programa no dia a dia em C.
Isto não significa que eu não tenha estudado e continue estudando C++. Ainda outro dia eu tomei um susto ao abrir um livro de C++ (de 94) e descobrir que eu não só tinha lido como tinha feito correções nos exemplos. E afinal, eu passei no exame de Visual C++ da Microsoft.
Na verdade, comecei a ter algum interesse em C++ no final dos anos 80. Nesta época chegamos a comprar na Humana uma cópia de um dos primeiros compiladores C++ para o DOS, o Zortech (que alguns anos depois foi comprada pela Symantec). A Borland foi uma grande divulgadora do C++, com o Turbo C++ e o Borland C++; lembro de um vídeo da Borland chamado "The World of Objects" (ou algo parecido). Em 92 a Humana fez um primeiro projeto em C++, usando o Microsoft C/C++ 7.0 (o primeiro compilador C++ da Microsoft).
Na Seal, fizemos alguns projetos com o Visual C++ 2.0 para serem rodados no NT 3.1 (ambos novidade na época). Alguns dos meu programas usavam até a MFC (então na versão 3.0). A maioria dos desenvolvimentos na Seal era feito em Visual C++ 1.5, para coletores de dados com sistema DOS. Eventualmente alguem teve a idéia de fazer uma biblioteca de classes para facilitar o desenvolvimento para os coletores. Embora eu não estivesse na época trabalhando na área de software, alguem me passou a especificação para dar os meus palpites. A especificação começava com uma classe CString (como se o VC 1.5 já não tivesse duas classes de string) e terminava com uma classe CUtil cujos membros eram funções diversas (para deixar tudo orientado a objeto?). No final a classe CUtil foi abandonada, mas a CString ficou lá.
Foi lendo esta especificação e a coluna de dúvidas de C++ do Microsoft System Journal que eu concluí que conceitualmente o C++ é bem mais pesado que o C. Recentemente escrevi um artigo sobre construtores no Wiki, e foi um trabalho bastante árduo para descrever algo que é simplesmente básico (quem usa C++ no dia a dia tem que ter tudo isto e muito mais na ponta da lingua). Talvez por isso eu continue usando C mesmo quando o C++ é uma opção disponível. O fato de eu estar cercado de outros programadores C também contribui, principalmente porque eu sempre tenho a esperança de deixar a manutenção para eles.
Isto não significa que eu não tenha estudado e continue estudando C++. Ainda outro dia eu tomei um susto ao abrir um livro de C++ (de 94) e descobrir que eu não só tinha lido como tinha feito correções nos exemplos. E afinal, eu passei no exame de Visual C++ da Microsoft.
Na verdade, comecei a ter algum interesse em C++ no final dos anos 80. Nesta época chegamos a comprar na Humana uma cópia de um dos primeiros compiladores C++ para o DOS, o Zortech (que alguns anos depois foi comprada pela Symantec). A Borland foi uma grande divulgadora do C++, com o Turbo C++ e o Borland C++; lembro de um vídeo da Borland chamado "The World of Objects" (ou algo parecido). Em 92 a Humana fez um primeiro projeto em C++, usando o Microsoft C/C++ 7.0 (o primeiro compilador C++ da Microsoft).
Na Seal, fizemos alguns projetos com o Visual C++ 2.0 para serem rodados no NT 3.1 (ambos novidade na época). Alguns dos meu programas usavam até a MFC (então na versão 3.0). A maioria dos desenvolvimentos na Seal era feito em Visual C++ 1.5, para coletores de dados com sistema DOS. Eventualmente alguem teve a idéia de fazer uma biblioteca de classes para facilitar o desenvolvimento para os coletores. Embora eu não estivesse na época trabalhando na área de software, alguem me passou a especificação para dar os meus palpites. A especificação começava com uma classe CString (como se o VC 1.5 já não tivesse duas classes de string) e terminava com uma classe CUtil cujos membros eram funções diversas (para deixar tudo orientado a objeto?). No final a classe CUtil foi abandonada, mas a CString ficou lá.
Foi lendo esta especificação e a coluna de dúvidas de C++ do Microsoft System Journal que eu concluí que conceitualmente o C++ é bem mais pesado que o C. Recentemente escrevi um artigo sobre construtores no Wiki, e foi um trabalho bastante árduo para descrever algo que é simplesmente básico (quem usa C++ no dia a dia tem que ter tudo isto e muito mais na ponta da lingua). Talvez por isso eu continue usando C mesmo quando o C++ é uma opção disponível. O fato de eu estar cercado de outros programadores C também contribui, principalmente porque eu sempre tenho a esperança de deixar a manutenção para eles.
Assinar:
Postagens (Atom)