Evento Comunidade PontoNetPT

Este documento tem o objectivo de fazer passar a informação a que tive o privilégio de receber no primeiro evento da nossa comunidade de programadores .NET em Portugal.

Caso alguém esteja interessado a ser membro da comunidade: www.pontonetpt.pt

ASP.NET - Técnicas para melhorar performance

O Viewstate foi intensamente aprofundado, a performance de uma aplicação web depende muito do que fazemos com o Viewstate.

O Viewstate está ligado por defeito em todos webcontrols, sendo assim reparem que quando utilizamos um Botão o ViewState está ligado por isso estamos a pesar o servidor e seus downloads/uploads com o cliente quando na verdade não precisamos de estar a guardar estado desse controlo, só precisaríamos do Viewstate nesse controlo se quiséssemos manipular o Caption do botão.

Sempre que pudermos devemos utilizar HTML Controls ou então usar Web Controls mas ter o cuidado de desligar sempre o Viewstate quando não precisamos dele, reparem uma label que não vamos precisar de manipular o seu TEXT para que guardar estado???

Mas o Viewstate é muito importante também, se quisermos manter dados de uma página, por exemplo uma combobox que foi carregada no inicio da página com o Viewstate não precisamos de estar sempre a carregar esses dados a cada Request.

Existem técnicas muito interessante para comprimir os dados do html a enviar para o cliente:

• Comprimir os dados ao nível de parametrização do Servidor IIS

Esta funcionalidade é muito interessante apesar de a compressão só ser efectuada nos downloads (html enviado ao cliente) isto porque os browsers não conseguem enviar os dados comprimidos para o servidor.

Esta técnica de compressão no IIS para funciona com as ASP.NET não basta ir aos parâmetros do Servidor IIS indicar que queremos comprimir, existe um ficheiro XML de configuração no IIS que temos que o editar a mão para incluirmos a extensão de ficheiros aspx, este ficheiro só pode ser alterado com o serviço do IIS parado.

• Comprimir o Viewstate

Existem livrarias que podemos usar para comprimir o nosso Viewstate exemplo: SharpZipLib ou LZO são compressores do Viewstate eles comprimem em Strings Base64 o qual conseguimos diminuis os Kb a enviar e a receber do cliente em cerca de 50%.

• Suprimir o ViewState

Uma técnica também muito interessante é suprimir o Viewstate e guardar os seus dados de estado no servidor, onde o que vai apenas dentro do Viewstate será um ID de referencia para aquela sessão e aqueles dados que guardou, com esta técnico tornamos a performance de comunicação dos dados html muito interessante mas temos que engordar o nosso servidor de memória.

• Produtos de Compressão

Existem também produtos que estão a ter um grande sucesso na forma como interagem com o IIS na questão de optimização e compressão de dados, um caso de sucesso é o produto ASPAccelerator, onde existem já muitos casos de sucesso no nosso pais com a utilização deste produto. AciNet é uma empresa que utiliza fortemente este produto nas suas soluções de webapplication.

Agora uma coisa é certa todas estas técnicas de optimização deverão ser utilizadas de forma a que consigamos encontrar o equilíbrio perfeito, para não saturarmos o servidor, não devemos esquecer que qualquer processo de compressão e descompressão vai fazer carga no CPU, assim como também guardar estados no servidor vai ocupar memória.

Ferramentas e estratégias de desenvolvimento

Foram abordadas algumas ferramentas para nossa utilização no desenvolvimento de ideias. Estas ferramentas ajudam-nos a definirmos a nossa ideia e a divulga-la junto dos nossos clientes, são ferramentas que através de símbolos gráficos ajudam a representar as soluções.

Aqui ficam algumas destas ferramentas existentes no mercado:

• Visual Mind                               http://visual-mind.com
• FreeMind                                   http://freemind.sourceforge.net
• MindManager                             http://www.mindjet.com
• SmartDraw                                http://smartdraw.com
• ConceptDraw MINDMAP http://www.conceptdraw.com/en/products/mindmap

Uma ferramenta também mencionada para melhorar a nossa produtividade é o CodeSmith http://www.ericjsmith.net/codesmith/. Esta ferramenta gera código baseado em templates onde podemos criar os nossos próprios templates para criar stored procedures, funções, propriedades e etc. É FREEWARE.

Outro tipo de ferramenta também importante para quem tem que gerir projectos ou até mesmo o programador que pretende ter as suas tarefas bem planeadas com datas e etc, deixo aqui também alguns produtos:

Gestão do Projecto:

• Microsoft Project
• Task Tracker (shareware)                        http://positive-g.com/tasktracker
• MasterList-XL (free app.excel)     http://freemind.sourceforge.net
• Working Time Tracker                            http://www.allnetic.com
• A to Z Project Billing                              http://www.atozedsoftware.com/project

Bug Tracking:

Gemini (máx10 users)                http://www.countersoft.com/Gemini.aspx

FogBUGZ                                  http://www.fogcreek.com/FogBUGZ/

BugTracker (free)                       http://btnet.sourceforge.net/bugtrackernet.html

Bug-tracking tools list                 http://testingfaqs.org/t-track.html

Não sei como pude viver até aqui sem a utilização do FxCop http://www.gotdotnet.com/team/fxcop/

Está ferramenta é excelente analisa o nosso código para nos indicar se estamos a utilizar as boas práticas de desenvolvimento e se não estamos a ser prejudicados em termos de performance, tudo isto baseado na Microsoft .NET Framework Design Guidelines.

Através de utilização de reflection, MSIL parsing e callgraph analysis to inspect assemblies conseguimos verificar mais de 200 defeitos de desenvolvimento nas seguintes áreas:

• Library design
• Localization
• Naming conventions
• Performance
• Security

Por fim ainda com o FxCop podemos criar as nossas próprias regras de desenvolvimento internas da nossa equipa de desenvolvimento.

Foi falado também no gerador de documentação NDoc, mas isso já não é novidade para ninguém, eu jurei a mim mesmo que os meus futuros projectos iria documentar função por função enquanto fosse escrevendo as linhas de código, pois só assim é que conseguimos ter a documentação técnica do que produzimos no fim do projecto.

Hora aqui está uma coisa muito interessante, ver o código dos outros… Sim é verdade com tecnologias como o MSIL, ILASM ou mesmo Reflector podemos ver o que faz um determinado componente mesmo compilado em formado DLL ou EXE, então o Reflector danos mesmo o próprio código em C# ou VB.NET do código que foi escrito. Como podemos fazer para proteger o nosso código? DotFuscator ou outras ferramentas do género conseguem “baralhar” todo o código para ser uma cifra de códigos de “quebra cabeça”.

Desenvolvimento de Testes Unitários com o Nunit

TDD ou Test-Driven Development será o futuro para não “desenvolvermos bugs”?

Isto não só é uma tecnologia mas sim mudar a forma como pensamos e como fazemos.

A tecnologia chama-se NUnit, o que isto faz? Ao instalarmos a NUnit ficamos com mais um tipo de projecto que podemos criar no nosso Visual Studio.

http://www.nunit.org/

What Is NUnit?
NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current version, 2.1 is the third major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.

Ao invéz de criarmos o nosso componente e depois irmos testa-lo, porque não criarmos o teste que queremos fazer e depois sim o componente?

Pois é aqui que dá a volta a nossa cabeça, vou tentar explicar:

Criamos a nossa solução, criamos o nosso projecto e começamos a trabalhar normalmente, mas quando vou criar o meu primeiro método crio primeiro através de Atributos o teste que quero fazer ou o objectivo que quero atingir, com isto se eu compilar será o compilador a avisar-me do que eu pretendo e que ainda não existe! Ok, então se não existe eu crio e assim aquele teste que eu tinha programado já vai ser satisfeito e dai por diante.

O que vamos conseguir com a utilização do NUnit?

• Termos a certeza do que precisamos na realidade de desenvolver e não criar uma rotina que talvez venha a ser precisa ou talvez não, com isto vai poupar muito lixo de código criado.
• O NUnit me informará que código foi testado e qual não foi, como também qual a percentagem de código da minha aplicação está testado, que confiança posso ter no estado do meu projecto.
• Podemos criar projectos para testar os nossos projectos, o que é isto? É conseguirmos testar os nossos componentes sem que tenham que ser lançados pela aplicação de UserInterface, podendo assim ir testando por unidades, componente por componente.
• Com as extensões do NUnit (NUnitForms ou NUnitAPS) podemos também testar os nossas interfaces com o utilizador.
• O que para mim é muito interessante é quando o nosso projecto já é demasiado grande e temos que efectuar uma alteração ou acrescentar algo, temos sempre o receio que venha a colidir com qualquer outra rotina, esta forma de trabalhar garante que ao compilar podemos efectuar todos os testes que foram programados desde o início e que resultados queríamos atingir, o NUnit produzirá um relatório a informar onde estamos a ter problemas com essa alteração.
• Por fim, os testes podem ser tão completos que podemos criar Mock Objects para simular serviços que não estão dentro da nossa solução, como web services de terceiros ou outros aplicativos que tenham que interagir com o nosso.

Usando o CruiseControl.Net e ferramentas associadas para montar um processo de Integração Contínua

http://confluence.public.thoughtworks.org/display/CCNET

Processo de integração contínua? Builds diários? Alguém já ouviu falar disto?

Com um processo de integração continua podemos ter um servidor de builds ou melhor um servidor que a cada 5 minutos vai ao sourcesafe buscar as últimas alterações, faz um build caso exista erros reporta essa informação através de um site na nossa intranet ou envia informação de alerta aos programadores por email, netsend ou via tryicon tipo messenger, caso tenha sucesso no build então irá passar por todo processo, que se compreende em verificar os testes por meio da NUnit, verificar as normas/regras de boas práticas, criar label no sourcesafe e etc.

O CruiseControl.NET permite integrar qualquer processo que possa ser executado por command line, assim como:

• SourceSafe

• NAnt ou MSBuild
• NUnit
• FxCop
• NDoc
• etc.

Visualização dos resultados:

• [ASP.NET enabled Web Applications]
• HTML and plain-text email
• System Tray notification

Nota final:

É de ter em atenção que a maioria destas ferramentas são já tão importantes que mereceram a sua promoção ao Visual Studio 2005, quer isto dizer que já vêem integradas no produto.

Outubro 2004 - Sérgio Ferreira

Sofinloc - Desenvolvimento