Archive for the 'Uncategorized' Category

1º Coding Dojo DotNetFloripa – Diário de Bordo

Salve pessoal!

Ontem ocorreu o primeiro Coding Dojo do grupo DotNetFloripa. Acabei não anunciando aqui no blog (a lista de dois grupos me pareceu uma audiência um pouco maior :)), mas ao menos os resultados ficarão registrados por aqui.

A idéia do dojo surgiu numa troca de e-mails em que discutíamos possíveis temas de futuros eventos do grupo e, como eu nunca havia ouvido falar da expressão (vcs realmente já haviam? :)), saí pesquisando pelo Google, seguindo links, aquele processo habitual. Também habitualmente metido, enviei algumas sugestões e acabei abraçando a organização desse primeiro encontro. Muito gratificante!

Coding Dojo: evento onde um grupo de programadores, utilizando TDD e baby steps, tenta resolver um problema proposto de lógica. Todos dão pitacos e revezam-se no teclado e como “co-pilotos”, o que torna a interação muito maior. O grande objetivo não está na resolução do problema, mas sim na troca de informações e contato com novas idéias, tecnologias e formas de programar, o que sempre acaba agregando.

Não compareceram muitas pessoas (8 no total), o que acabou mostrando-se positivo no final do encontro. A interação e participação de todos ocorreu acima do esperado (pelo menos por mim), o que foi um dos pontos fortes do evento. Estava com um pé atrás pois nas reuniões do grupo que participei a interação do pessoal com o palestrante, no geral, não era das mais eloquentes. Nesse encontro, entretanto, todos contribuíram com idéias para o código, dúvidas e tudo mais. Como boa parte do pessoal ainda não utiliza TDD no dia a dia, boa parte do tempo foi utilizada discutindo alguns conceitos, explicando outros, etc, etc. Por este motivo acabamos não tendo tempo para concluir o problema, mas espero que não faltem próximas oportunidades.

No final, chegamos a uma lista de pontos positivos e outros que podemos melhorar para os próximos encontros:

Pontos positivos:

  • Número de participantes: mesmo não plenejadamente, foi consenso entre todos que um número de participantes maior que 10 pode inviabilizar a interação no dojo;
  • Prova do TDD: mesmo não tendo codificado tanto quanto deveríamos (construímos 4 métodos de teste) já foi possível exemplificar o valor do TDD quando, devido à alteração para um teste, outro anteriormente “green” passou a falhar;
  • Participação do pessoal: todos interagiram e sentaram-se pra programar, sem medo de ser feliz. Dicas de VS, frameworks, TDD, lógica e dúvidas surgiram aos montes. Muito legal;

Pontos a melhorar:

  • Conceituação de TDD: pela pouca experiência de parte do pessoal com TDD, a maior parte do tempo foi utilizada em conceito ao invés de programação. Apesar de também ser positivo, o ideal seria fazermos uma palestra sobre TDD para que pudéssemos simplesmente praticá-lo no Dojo (obs.: a palestra já está sendo agendada);
  • Tempo de cada piloto: não houve um controle do tempo que cada um passava programando, o que dificultava as trocas num tempo “justo”. Foi sugerido que utilizemos uma abordagem “ping pong”, onde um desenvolvedor implementa um teste falho e o próximo faz o teste corrigir. Muito válido;
  • Piloto “type only”: em mais de uma situação a pessoa que estava programando simplesmente digitava o que os outros iam falando, não dando oportunidade ao piloto e ao co-piloto de decidirem por um passo antes de serem questionados. Talvez o ideal seja dar mais autonomia ao piloto/co-piloto (definição do próximo teste falho, por exemplo) para depois virem sugestões, questionamentos e tudo mais;
  • Resolução do problema: não conseguimos resolver o problema dentro do tempo previsto, se na próxima deixarmos ele sobreviver novamente vai virar questão de honra.. 🙂

Se alguém quiser ver o PPT com a descrição do problema que tentamos resolver + conceitos de Dojo e TDD + código desenvolvido, coloquei tudo no RapidShare pra baixar. É só clicar aqui. Abaixo segue uma das fotos tiradas por lá do pessoal interagindo:

1oCodingDojoDotNetFloripa

Gostaria de agradecer ao pessoal do DotNetFloripa que compareceu no encontro pela presença e interação, ao pessoal do DojoFloripa pelo feedback positivo e representação (1 dos participantes era de lá! :)) e ao Ivan Sanchez (ex-DojoFloripa, atualmente em Londres) que me ajudou a esclarecer várias dúvidas e tornar esse primeiro encontro possível.

Comentários de qualquer tipo são bem-vindos. Até o próximo Dojo!

José Filipe

Anúncios

Rollback automático com NUnit

A situação é comum: você constrói um conjunto de testes unitários baseado em registros que estão salvos em um banco de dados e tudo funciona bem. O problema é que assim que os dados são alterados/apagados/inseridos pelo primeiro ciclo de testes, seus Asserts simplesmente deixam de funcionar – e você precisa de alguma maneira voltar a base ao seu estado original.

Bom, antes de qualquer coisa vamos deixar algo claro: provavelmente você não devesse estar dependendo de um banco de dados. Se você estiver testando sua camada de domínio, o ideal é que suas suas classes de controle consumam uma interface de suas classes DAO cuja dependência tenha sido injetada. Isto permitirá que você construa stubs de suas classes de acesso a dados, garantindo que seus testes rodarão rapidamente (e que você sempre tenha coragem para rodá-los!) e não dependam de um banco de dados para serem rodados.

Mas suponhamos que você tenha uma razão muito forte para querer depender de um banco de dados. Você pode estar testando a camada de acesso a dados em si, stressar seu database através de testes unitários ou simplesmente já possuir um conjunto muito grande de testes prontos que desencorajam o refactor (não é algo que você deva se orgulhar, mas coisas assim acontecem). Em qualquer um desses casos, você tem algumas opções:

  1. Escrever seus testes para que eles sejam auto-suficientes: uma boa prática, seguindo a “metodologia” AAA de testes unitários: Arrange, Act, Assert. Para alguns casos (com muitos registros envolvidos), entretanto, isto pode ser bastante trabalhoso (e demorado);
  2. Criar um backup da base que você roda os testes e restaurá-lo constantemente: menos trabalhoso, mas longe do ideal. Mesmo automatizando o restore via código trabalho adicional associado sempre que os dados fossem efetivamente alterados (para adição de novos testes, por exemplo);
  3. Recarregar os dados do database a partir de XML, DBF ou algo que o valha: uma opção legal e até bem difundida. Arquivos XML ou de qualquer outro tipo, entretanto, não são minha representação ideal de dados relacionais;
  4. E por último, é claro, a opção que falaremos aqui: utilizar o XtUnit, framework desenvolvido pelo Roy Osherove (uma espécie de bam-bam-bam dos testes unitários) que permite um rollback nos seus dados com um simples attribute de [DataRollBack].

Continue lendo o post completo..

Transformando DataSet para Excel através de XSL

Desde a época que comecei a trabalhar com desenvolvimento (e lá se vão mais de 5 anos :-)) transformar informações carregadas do banco de dados em Excel é uma tarefa presente. Naquela época o sistema era feito em Delphi 5 e utilizávamos uma classe que encapsulava o objeto COM do próprio Excel. O programador que quisesse aquela funcionalidade em sua tela de exportação, com seu próprio layout de arquivo, tinha que realizar loops aninhados e desbravar o mundo dos objetos não tipados (tipo var no Delphi) pra conseguir setar cores, dados, fontes, formato de número e tudo mais.

Já não desenvolvo mais em Delphi há algum tempo e provavelmente hoje exista algo mais simples pra criar arquivos Excel a partir de DataSets ou algo que o valha na linguagem (talvez até já existisse aquela época e eu que não conhecesse), mas a questão é que a demanda permanece e, mesmo no mundo .NET, as soluções utilizadas, em sua maioria, não são exatamente simples. Com esse post pretendo mostrar como criar arquivos Excel a partir de DataSets com ASP.NET de uma maneira bastante simples e direta.

Continue lendo o post completo..

NHibernate – Mapeando valores default como null: IUserType, IParameterizedType

Fala pessoal!

Faz um tempo que não escrevo (sempre o mesmo papinho), mas baterei o incrível recorde de 2 posts técnicos num mesmo mês com esta postagem, então minha motivação está lá em cima! Na verdade, este post servirá como guia para algumas coisas do trabalho, e isso acaba sendo um “motivador” e tanto..

Apesar de ser a primeira vez que o tema será abordado aqui, acredito que todos que lêem o blog (ou mesmo os que aterrisam aqui esporadicamente) já tenham utilizado ou pelo menos ouvido falar do NHibernate. O NHibernate é um framework de mapeamento objeto relacional para .NET, portado do excelente Hibernate (Java), que facilita sua vida em gravar e recuperar objetos do banco de dados. Acaba ajudando também a manter uma OO mínima, já que sem isso o trabalho fica muito mais doloroso, o que também é muito positivo.. O NH permite mapear diversos tipos de colunas, trabalhar com chaves geradas automaticamente e mais uma infinidade de coisas que nem uma centena de posts conseguiriam cobrir.

O fato é que, nesta semana, caímos num problema com campos que possuem valores default. Contextualizando: possuímos uma grande aplicação que foi desenvolvida originalmente em .NET 1.1 e hoje encontra-se e .NET 2.0. Na época do 1.1, tipos “nullables” não passavam de um sonho e as pessoas arrumavam soluções criativas para contornar a questão: criando structs próprios, utilizando valores default, etc. As soluções não eram exatamente o sonho de nenhum desenvolvedor, mas, dada as restrições do framework, funcionavam bem desde que fosse mantida certa disciplina. Neste projeto a solução utilizada foi a de valores default. Alguns campos são inicializados com extremos de seu tipo (ex.: Int32.MinValue) enquanto outros assumem valores “mágicos” (ex.: -1, 03/03/0003). No momento da persistência, estes valores são tratados pela camada apropriada (aquela mesma citada por problemas de performance em outro post) e transformados em DbNull (ou vice-versa).

Continue lendo o post completo..

Testes Unitários com NUnit

Fala pessoal!

As coisas têm estado bastante corridas nas últimas semanas, motivo pelo qual terminei o mês de abril com o impressionante número de 1 post. Mas em maio o objetivo é mudar isso: no mínimo 2, :)..

Nas últimas semanas tenho lido bastante sobre testes unitários, inversão de controle (e injeção de dependência), princípios SOLID e algumas outras práticas defendidas pela comunidade ALT.NET.

Apesar de testes unitários já serem tópico de atenção há muito tempo e eu ter uma clara noção de como eles funcionavam, tenho que admitir que nunca os havia utilizado na prática. Como um post do Karl Seguin, via CodeBetter, nesta semana falou do assunto também e alguns projetos na empresa seriam bastante beneficiados, pensei: é hora de dar uma pesquisada e de quebra tirar a poeira do blog!

Pra demonstrar um projeto com testes unitários básicos eu vou utilizar o NUnit. O VS2008, na edição Team System, também pode fazer testes unitários, mas minha escolha baseia-se no fato de eu não apoiar o recorrente comportamento “anti open frameworks” da MS. Além do custo do VS ser absurdo, eu realmente gostaria de poder participar de uma comunidade cada vez mais ativa sem depender da MS pra tudo. Nesse quesito é indiscutível a superioridade do Java (na verdade de sua comunidade) sobre o .NET, e pra mim grande parte desta culpa pertence à MS..

Continue lendo o post completo

Code Profile com Visual Studio 2008

Olá pessoal!

Performance de aplicações sempre foi e continuará sendo causa de muita discussão – e invariavelmente de muitos problemas também.

Até pouco tempo atrás, pensar em profile de código era tido quase que como inviável, dada a complexidade e quantidade de recursos exigidas por este tipo de ferramenta.

O Visual Studio 2008 trouxe um recurso de profile de código muito interessante, possibilitando em poucos cliques é possível descobrir os pontos de seu código que estão consumindo mais recursos e otimizá-los.

Como o conjunto de recursos é razoável, demoraria um bocado pra escrever um post completo, então resolvi criar um vídeo com os principais pontos. Já aproveito e testo a aceitação do recurso por aqui.

Vídeos do VodPod não estão mais disponíveis.

O código fonte da aplicação de teste, para os que quiserem reproduzir, pode ser baixado aqui.

Para os que quiserem entender um pouco melhor, saiu na MSDN Magazine de março um artigo sobre o tema (fonte de inspiração pra esse aqui :)).

Comentários e dúvidas sobre o assunto são incentivados, bem como a opinião sobre a utilização do vídeo no lugar do texto escrito.

Abraços e até a próxima!

Zé Filipe

XmlSerializer e sGen.exe – Melhorando Performance

Utilizamos há algum tempo aqui na empresa uma camada caseira de acesso à dados que salva as configurações dos diferentes servidores e bancos de dados a serem acessados em um arquivo XML. Este arquivo XML, por sua vez, é lido pela biblioteca através da classe XmlSerializer (System.Xml.Serialization), que o transforma numa coleção de objetos com apenas duas linhas de código.. simples e configurável, sempre nos pareceu uma excelente opção!

Tudo corria bem até que um de nossos produtos começou a ganhar uma escala até então inédita para nós num único servidor, e a criação das classes de acesso a dados começou a ficar bastante lenta. Fuça daqui, revira de lá, chegou-se à conclusão que a serialização do bendito arquivo XML estava consumindo processamento demais. Como não suspeitamos do .NET Framework 1.1 (sim, ainda estávamos nele no ano passado), acabamos criando uma Factory que centralizava numa coleção estática todas coleções desserializadas pela aplicação, realizando o controle da modificação do arquivo através da classe FileSystemWatcher (System.IO). A performance melhorou e tudo parecia estar mais uma vez sob controle..

Como nada dura para sempre, entretanto, aconteceu desta mesma camada de acesso a dados ter problemas com concorrência. Coincidentemente, no meio dessa análise de concorrência, ocorreu também de eu receber um link para o recurso de profiling de código do VSTS (assunto para um próximo post) e, adivinhem, não é que a leitura do XML continuava consumindo tempo demais?

Tudo bem que a performance dificilmente estaria ligada aos problemas de concorrência, mas era preciso entender o porquê daquilo. Procedimento padrão: Google -> XmlSerializer performance e… batata! Caí num artigo sobre um problema de performance com o XmSerializer e seus workarounds para os frameworks 1.1 e 2.0+. O que acontece, em resumo, é o seguinte:

  • Ao criar uma instância da classe XmlSerializer com os construtores XmlSerializer(type) ou XmlSerializer(type, string), o .NET Framework cria automaticamente o serializador e desserializador daquele tipo, criando um assembly para armazená-lo (sim, isso mesmo, um assembly é criado em tempo de execução)..
  • No .NET Framework 1.1, isto era feito à cada chamada do construtor, independente se aquele tipo já foi criado ou não! Incrível, não? Alguém se habilita pra chutar por que tínhamos problemas de performance? Existe um workaround no artigo que linkei acima para este caso, mas não testei por não ser o foco;
  • Já no .NET Framework 2.0+, isto é feito assim que a classe é criada e o assembly é reutilizado no caso de reincidência de construção daquele tipo. Bem melhor, mas longe do ideal para sistemas em que a performance é crítica..

A grande melhoria de performance vem com o fato de que é possível, através de um utilitário de linha de comando chamado sGen.exe (acessível pelo VS promt) criar uma pré-compilação de todos esses tipos que vão ser serializados. É possível compilar todos os tipos de uma DLL ou somente alguns (sgen MeuAssembly.dll, para todos, por exemplo). Também é possível, nas opções de Build do projeto no próprio VS habilitar uma opção chamada Generate Serialization Assembly, que vai fazer exatamente o mesmo trabalho. Em ambos os casos, é gerado na pasta de build um arquivo com o nome MeuAssembly.XmlSerializers.dll, que quando jogado na sua pasta \bin reduz, e muito, o tempo de criação da classe XmlSerializer.

ATENÇÃO: O arquivo não será gerado caso seu Assembly possua classes ou tipos cujo nome coincida com tipos do .NET Framework ou mesmo existam duas classes com o mesmo nome em namespaces diferentes. Nesse caso, os tipos em questão devem ser decorados com os attributes de System.Xml.Serialization (XmlType em específico) para adquirir um nome ou namespace único! No caso de problemas, rode diretamente pelo sGen para ganhar mensagens mais detalhadas.

É isso! Esta pode não ser uma situação das mais corriqueiras mas que pode destruir a performance de sua aplicação, então é sembre bom ficar atento!

Abraços!

Zé Filipe


Perfil

Olá! Meu nome é José Filipe e sou o autor deste blog. Trabalho como Gerente de Desenvolvimento da todo! BPO, onde sou responsável pela manutenção e evolução de pessoas, processos e sistemas desenvolvidos em diferentes tecnologias. Atualmente curso uma especialização em Engenharia de Software pela PUCPR, em Curitiba, mas moro em Florianópolis, onde me graduei em Sistemas de Informação pela UFSC. Possuo o título de MCP e com base nas experiências do dia-a-dia espero trazer ao blog assuntos interessantes sobre arquitetura e desenvolvimento .NET..

Arquivos

Páginas

novembro 2017
S T Q Q S S D
« jun    
 12345
6789101112
13141516171819
20212223242526
27282930