Blogging

logo-sun

Uma nova linguagem

4

 

Tenho que me atualizar. Faz um tempo (anos) em que deixei de lado esse mundo "frescurento" de C++2030 e me foquei única e exclusivamente em resolver problemas da melhor forma possível com o que a linguagem já tinha a oferecer em uma implementação estável de compilador e bibliotecas.

Agora o mundo está mudando. Para quem é do Universo Windows/Microsoft, a empresa do Uncle Bill vem liberando algumas versões interessantes do seu compilador (VS2012, 2013 e agora o CTP), cada vez mais próxima de um C++11/14 100% compliance. Não acredito que cheguem lá, mas o fato de estarem empenhados indica para a indústria e seus clientes que há uma demanda sendo atendida. Não é mais frescurite de acadêmicos. Algumas features ultra-novas começam a ser usadas e permitidas em projetos.

Estamos falando de uma nova linguagem que se forma com um novo ritmo. O padrão C++11 demorou "apenas" 2 anos para cair em nossas linhas de comando, há um patch já confirmado para o ano que vem e já existem menções para um novo release em 2017. Para o programador C++ que se acostumou a contar as evoluções em décadas, um novo ritmo se impõe. Não há tempo para cristalização de conceitos. O boost já nos forneceu isso por todos esses anos e hoje ele é reconhecidamente a versão alpha que precisávamos.

Veremos o que o futuro cada vez mais presente nos reserva.

ShowCast

MVP ShowCast 2013: C++11 e C++14 no Visual Studio 2013

4

ShowCast

Uma notícia meio relâmpago (leia "publicada tarde demais"): amanhã (Segunda-Feira, 02/12/2013) às 17:00 (horário de Brasília) será exibida uma web-palestra web-ao vivo pelo web-Strauss e moderada por web-mim. O assunto é: todas as bugingangas novas que o recém-chegado Visual Studio 2013 suporta da (praticamente) nova linguagem C++11 (e seu amigo do futuro, C++14).

Estarei me guiando pela tabela da MSDN que relaciona essas novidades entre as diferentes versões do Visual Studio. São muitas mudanças de uma vez só, e pode haver detalhes obscuros que eu ainda não ouvi falar, mas tentarei obter o máximo de informações possíveis para juntos tentarmos extrair o que pudermos nessa 1 hora e 15 minutos de web-interatividade.

Quer se inscrever? Acesse o web-linque do evento e nos aguarde por lá!

Update

 

O evento foi realizado e gravado e em breve tanto o áudio quanto os slides estarão disponíveis. Foi uma explicação sucinta sobre as novidades da linguagem, mas muito bem explicada por Strauss, o que deve ajudar a galera a se atualizar aos poucos.

Não foi uma palestra muito popular, talvez pelo dia/horário, mas tivemos a participação de cerca de 7 pessoas. A avaliação final não reflete isso, mas pudemos contar com uma série de perguntas pertinentes do participante Andre.

PoolVS2013CPP11

 

Update 10/12/2013

 

Seguem os slides da palestra:

mvp

Mais um CPP MVP

27

Tenho o prazer de informar à comunidade C/C++ que vocês possuem mais um representante formal. Quer dizer, pelo menos no que diz respeito à Microsoft: eu.

MVP.CPP

Graças à indicação de meu amigo Strauss (segundo MVP brasileiro seguido de Fabio Galuppo) e do meu histórico de artigos no blogue (alguns no Code Project), além da minha parca contribuição à comunidade C/C++ Brasil, recebi essa que significa uma nomeação importante não apenas para mim, mas para fortalecer a imagem de que existe uma comunidade da linguagem no país e está tão ativa que vira e mexe premia um ou outro membro mais "tradicional" desse grupo de especialistas, verdadeiros mestres dessa(s) que ainda é (são) minhas linguagens favoritas no que diz respeito a "linguagens de uso geral multiplataforma e de alta performance".

O que deve ocorrer com essa nomeação, acredito eu (tenho fé), é que eu volte a dedicar parte do meu tempo a "espalhar a palavra", seja aqui no blog, no nosso mundialmente conhecido grupo ou em outros cantos da internet. É hora de diminuir meu ímpeto cinéfilo e voltar a colaborar com os que buscam aprender algo mais do que pura lógica: a escovar os bits com água e sabão (e WinDbg).

Obrigado a todos os envolvidos! =)

Update

Dando uma vasculhada no saite de MVPs da Microsoft, por região, também encontrei o José Antônio Leal Farias, que de acordo com sua biografia reside em Campina Grande (PB) e trabalha com jogos.

VisualStudioWithVim1-3

Melhor integração entre Vim e Visual Studio

2

Pelo menos é a mais rápida:

VisualStudioWithVim1-3

 

VisualStudioWithVim2-3

 

VisualStudioWithVim3-3

 

Observações Finais:

  • O comando usado coloca o cursor na linha e coluna em que o editor da Microsoft estiver.
  • Para quem é fã de atalhos, basta digitar Alt+T seguido de V que voilà!
  • Não, usar aquele plugin não irá tornar o Visual Studio menos tolerável (não se você tiver o Vim instalado).
new-mobile-project

Depuração na nuvem com o novo Visual Studio

3

Uma das novidades do futuro Visual Studio pouco comentada ainda em fóruns por seu caráter sigiloso e ainda em testes (mas que pode facilmente ser observada pela engenharia reversa dos binários do Visual C++) é a possibilidade de depurar trechos de código "na nuvem", ou seja, dentro dos gigantescos servidores de clusters de serviços de escalabilidade da Amazon, do Google e, claro, da Microsoft.

new-mobile-project

Já é conhecido que será possível inserir comentários no código-fonte com o formato @nickname e incluir na listagem de bugs o estilo das #hashtags para que programadores vinculados à sua rede social possam enxergar referências a outros programadores e verificar o Developer TrendTopics, como um #blame-joel-on-software. Porém, o que poucos sabem, é que será também possível depurar as APIs de redes sociais em tempo real. Ou seja, caso seja usado o método Twitter::Tweet(), logo após o retorno da chamada será possível aguardar por uma resposta dos usuários envolvidos:

Twitter::Tweet
push ebp
mov ebp, esp
000007f9`bd590000 call __internal_tweet
000007f9`bd5900ac call _checkesp
000007f9`bd5900af ...
000007f9`bd5900ff ...
000007f9`bd59015f call __internal_wait_for_replies
000007f9`bd59017f pop esp
...

Ou seja, logo será possível além de perder horas navegando em saites de rede social perder também horas depurando os comentários e respostas das pessoas nessas redes direto do Visual Studio. É a Microsoft pensando nos programadores que gostam de perder tempo se envolver com pessoas (ainda que virtuais) e discussões acaloradas sobre tópicos irrelevantes e absurdos (ainda que virtuais).

Untitled2

10° Encontro de Programadores de C & C++

4

Ando tendo alguns problemas de postagem no meu blog, por isso o aviso não foi feito com mais antecedência. Peço desculpas aos organizadores do evento, pois sei que todo tipo de divulgação é útil.

Chegamos em mais um evento do grupo C/C++ Brasil, dessa vez honrando a parte "Brasil" do nome. Sim, nosso próximo evento será fora de Sampa, mas ainda próximo, no Rio de Janeiro! Até onde eu sei, o primeiro que se tem notícia. Finalmente o grupo terá a chance de se reunir na terra de programadores C++ de referência internacional como Pedro Lamarão.

Os detalhes do evento estão, logicamente, no saite oficial do grupo. Ele ocorrerá no dia 25 de maio (ainda dá tempo de comprar passagem) e terá sua programação divulgada já em abril. Infelizmente o tempo para o call for papers quase se esgotou (vai até dia 30 desse mês).

Enfim, essa é a chance de intercâmbio esperada entre nossa comunidade de programadores C/C++ de outras partes do país e que ainda não tiveram a oportunidade de participar dos nossos tradicionais encontros.

Correção: esse encontro foi o décimo, diferente do inicialmente proposto. Ou mudamos a base para 8 =P

Atualização: o encontro rolou, pelos comentários foi bem legal e em breve teremos slides, vídeos, depoimentos e etc.

horse21

eXtreme Go Horse

4

O Go Horse Power (GHP) foi criado por um blogue hoje extinto. As premissas dessa nova metodologia de desenvolvimento era que o projeto fosse feito da maneira mais rápida possível.

Contudo, eles não contavam com a versão turbinada do desleixo humano.

A eXtreme Go Horse (XGP) é o suprassumo das metodologias do mercado brasileiro de desenvolvimento. Quem nunca trabalhou em uma empresa gerida por essas regras? (Bom, pelo menos XGH pelo jeito tem até controle de fonte, algo que era até meio raro uns anos atrás):

1- Pensou, não é XGH

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida

2- Existem três formas de se resolver um problema

Estas são: a correta, a errada e a XGH, que é igual à errada, só que mais rápida. XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update

Se der merda, a sua parte estará sempre correta.. E seus colegas que se fodam.

7- XGH não tem prazo

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco)

8- Esteja preparado para pular fora quando o barco começar a afundar…

Ou coloque a culpa em alguém ou algo. Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa

9- Seja autêntico, XGH não respeita padrões

Escreva o código como você bem entender, se resolver o problema, commit e era isso

10- Não existe refactoring, apenas rework

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8)

11- XGH é totalmente anárquico

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4)

12- Se iluda sempre com promessas de melhorias

Colocar TUDO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10)

13- XGH é absoluto, não se prende à coisas relativas

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal

Scrum, XP…Tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade

15- XGH nem sempre é POG

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão dez vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

 

Este texto foi copiado daqui e daqui. Não existem donos conhecidos do XGH (já devem ter morrido de desgosto). Fiquei com medo de não encontrar mais essa metologia, que é pouco divulgada e muito útil.

Palestra TDC2012

Minha palestra do TDC 2012

4

Duas semanas atrás rolou a trilha C++ do TDC 2012, que contou com além da minha presença com a dos já conhecidos Fernando Roberto (DriverEntry), Rodrigo Strauss (1Bit), etc. Uma novidade: meu colega e programador .nerd Gabriel Guilherme também participou em uma palestra sobre um assunto que acredito que deveria ser mais promovido: interop. Afinal de contas, o poder de C++ não seria nada se não houvesse motivos práticos para usá-lo. Entre esses motivos, construir soluções com linguagens mais acessíveis é um deles.

Na minha palestra foquei no conteúdo dos meus dois artigos sobre um fictício Patch de Emergência (parte 1 e parte 2). No entanto, para agregar um pouco de valor ao conteúdo, estendi os exemplos para fornecer os caminhos para o desenvolvimento de uma solução profissional e usável de um quem-sabe real patch desses (ouvi falar que empresas como Microsoft utilizam isso).

Patch de Emergencia from Wanderley Caloni

Os fontes e a apresentação se encontram no meu já conhecido branch de exemplos no GitHub, mas para quem não sabe do que eu estou falando segue um linque com um pacote 7zip.

Meus repositórios no GitHub

0

Depois de vacilar por alguns meses, incentivado pelo meu amigo Chico Pimenta, resolvi experimentar o tal do GitHub, e consequentemente o sistema de controle de fontes distribuído Git, que antes era meio exclusivo do Linux (continua meio sendo, mas com suporte um pouco melhor para Windows).

Com isso, dei uma pequena lida no livro de introdução e comecei a migrar meus fontes perdidos num canto do HD. O que notei de vantagem com relação a outros DRCSs foi que é muito fácil e rápido criar branches e que a comunicação remota e os commits são feitos de uma maneira mais organizada e estruturada, além da própria estrutura interna do repositório ser muito simples de entender: um bando de arquivos compactados cujo nome é o hash do que ele contém.

Meus  repositórios estão armazenados em alguns branches que distribuí de acordo com o uso/importância:

  • OpenSource. Projetos de fonte aberto que mantenho/ive e que poderiam se perder se alguém não fizesse backup (como o mouse tool ou regmon).
  • Samples. Códigos de exemplo, de palestras e de testes feitos para escrever os artigos do blogue cujo autor vos fala.
  • Caloni. Os códigos que fazem algo de útil, como o Houaiss2Babyulon, CopiaExata e DayToDay.
  • Book. Um projeto em estado de larva sobre escrever um livro de engenharia reversa. Já possui um índice básico. Sugestões são bem-vindas.
  • DriverEntry. Códigos do curso de desenvolvimento de drivers que estou fazendo com o Fernando, da DriverEntry Company. Recomendo!

Problemas comuns no WinDbg e suas soluções

0

Depois de uma agradável manhã e tarde acompanhando o curso de desenvolvimento de drivers do meu amigo Ferdinando voltei para a casa para brincar um pouco mais com o mundo kernel e voltar a encontrar problemas com o WinDbg & Cia que há mais ou menos 1 ano atrás não tinha.

Pesquisando por um problema específico envolvendo PDBs reencontrei o blogue do Ken Johnson, MVP Microsoft e analista por profissão e diversão, é conhecido por suas excelentes contribuições no mundo da depuração de sistema (notadamente WinDbg). Existe um post específico que ele escreveu para economizar tempo com problemas que ocorrem de vez em quando em uma sessão ou outra de depuração, mas nunca paramos tempo o suficiente para resolver.

Além de outros, ele lista alguns que particularmente já aconteceram comigo ou com colegas de depuração:

O WinDbg demora um tempo absurdo para processar o carregamento dos módulos e está usando tempo máximo de processamento em apenas uma CPU.

Isso ocorre porque existem breakpoints ainda  não resolvidos. Resolva deixando apenas esses tipos de breakpoints que são absolutamente necessários, pois cada vez que um módulo é carregado o depurador precisa fazer o parser de cada um deles para verificar se ele já consegue resolve-lo.

Às vezes, porém, existe algum lixo nos workspaces carregados por ele que permanecem mesmo depois de apagarmos todos os breakpoints inúteis ou reiniciar o sistema. Em último caso, sempre podemos apagar o workspace do registro, em HKCU\Software\Microsoft\Windbg\Workspaces.

O WinDbg continua demorando décadas para analisar o carregamento, mas agora nem consome tanta CPU assim.

Isso ocorre porque na cadeia de paths para procurar por símbolos existe algum endereço de rede/internet errado que faz com que ele tenha que caminhar em falso diversas vezes. Esse e outros erros de símbolos sempre poderão ser analisados através do universal !sym noisy, que imprime todo tipo de informação útil do que pode dar errado durante um .reload explícito (eu digitei) ou implícito (lazy reload).

O WinDbg continua recusando carregar um símbolo que eu sei que existe e sei que é válido.

Talvez ele exista, mas por algum motivo foi copiado corrompido para o symbol server. Mais uma vez, !sym noisy nele e deve acontecer algum erro de E_PDB_CORRUPT. Nesse caso, apague o PDB culpado e tente de novo.

E, como brinde, um grande aliado da produtividade: como evitar que o WinDbg bloqueie seu PDB enquanto você precisa constantemente recompilar seu driver:

.reload -u modulo

Fonte: Blog do Nynaeve.

Go to Top