Monthly Archives: August 2009

TechEd Brasil 2009

TechEd Brasil 2009

Tive a oportunidade de participar do Microsoft TechEd Brasil 2009, que ocorreu em São Paulo durante os dias 25, 26 e 27 de agosto. O que posso falar do evento? De maneira geral, foi excelente, super organizado e com conteúdo de primeira. Como nem tudo são rosas, o Lunch Box me deixou na mão, não havia ficado muito claro, pelo menos para mim, que eram lanches estilo McDonald’s, eu estava esperando um almoço normal em um restaurante normal, da próxima vez vou ler o FAQ antes.

General Session

O evento começou com uma apresentação geral com o histórico da Microsoft até hoje, o auditório da UNIP lotou, e foram necessárias mais quatro outras salas que estavam assistindo por streaming. Após essa volta no tempo, Waldemir Cambucci falou sobre o futuro na visão da Microsoft, resumindo os vários slides, o futuro está no S+S (Software + Serviços). Aqui tem uma enorme explicação sobre o assunto escrito pelo próprio Waldemir.

Nesta sessão houve também a presença do BOPE (Batalhão de Otimização de Plataformas Empresarial). Esse negócio de BOPE já ficou meio manjado, todo mundo faz isso agora, é a nova moda, mas eu confesso que deu para rir bastante.

Vou colocar aqui um resumo das palestras que eu assisti e achei mais interessante.

C# – Dicas, Truques e o futuro da linguagem com a versão 4.0 - Alfred Myers

Alfred começou a palestra mostrando um código curioso, você acha que é possível instanciar uma interface? Pois é, ele provou que é possível, mas é INCORRETO, nunca faça isso. Para os curiosos aqui está o how-to para este hack tosco.

As grandes mudanças serão:

ASP.NET MVC com jQuery: retome o controle da sua aplicação web - Giovanni Bassi

Nem foi tanto sobre ASP.NET MVC e jQuery, o que mais foi comentado foi sobre como montar uma arquitetura seguindo os princípios do SOLID. Ficou bem claro que projetar um software não é simplesmente sair programando, existe uma série de padrões e princípios que vão ajudar a construir um produto de qualidade e que seja durável.

Além do mais, foi dada a ênfase de que o framework MVC da Microsoft não é um substituto do WebForms, ele foi criado para atender aos desenvolvedores que procuravam construir softwares seguindo todos estes padrãos, e o WebForms não é o melhor framework para isso (principalmente quando no quesito testes automatizados). Esse ebook sobre SOLID é bem interessante, tendo exemplos em Ruby e C#.

Desenvolvendo aplicações com as novidades do Windows 7 - Bruno Sonnino

O Windows 7 trouxe algumas novidades para os desenvolvedores Desktop, o principal deles é a taskbar. O foco que a Microsoft deu para essa taskbar é incrível, você faz tudo nela. Segundo o palestrante, a tendência é que a tray (onde fica o relógio, geralmente no canto inferior esquerdo) seja removida do SO. Para desenvolver sobre essa nova plataforma você vai precisar de um API, chamada de Windows API Code Pack For .NET.

Na taskbar é possível criar barras de progresso, jump lists, atalhos, thumbnails e outra coisas mais. O maior problema é que se você tentar rodar isso em Windows XP ou Vista, você terá problemas. A saída é a compilação condicional, o que em minha opinião é bem tosco, vou precisar de unit tests adicionais para cada versão de SO.

Unit Testing – boas práticas e patterns - Cezar Guimarães e Fabio Vazquez

Uma das palestras mais interessantes, eu que já tenho certa prática com Unit Testing consegui aprender muita coisa nova, como por exemplo o FIRST (Fast, Isolated, Repeatable, Self-Validating, Timely), cada letra representa uma característica importante dos testes. No quesito de boas práticas conheci também o AAA, que é uma forma de organizar os testes. Não fazia idéia da importância da nomenclatura dos testes, eu sempre escrevi sem padrão nenhum, vou começar a seguir a recomendação deles (tirada do livro The Art of Unit Testing) onde o método deve ter o padrão:

<nome_do_método_a_ser_testado>_<o_que_você_vai_fazer>_<qual_o_resultado>
Play_WhenIClickPlayButton_ASoundShouldBePlayed
Stop_WhenIClickStopButtonWhileIsPlaying_SoundShouldStopPlaying

Testes de Software com Visual Studio Team System 2010 - Brian Keller

Outro palestrante que veio da Corporação, desta vez falando do VSTS2010. Basicamente o que foi dito é que o foco atualmente está sendo em automatizar os testes de API ou então de caixa branca. Os testes manuais também possuem importância, mas até então não havia foco do VSTS2010 nestes testes. Usando o novo Test Lab, os encarregados por executar os testes terão uma ferramente para fazer anotações, automatizar os testes manuais quando possível e outras coisas mais. O interessante é que pode ser rodado dentro de uma máquina virtual, então não teremos mais a famosa desculpa “Na minha máquina funciona”, o tester pode tirar um snapshot e enviar o time de desenvolvimento.

Conclusão

Fantástico, será que em 2010 tem outro?

Dica #3: Olá SGMLReader; Adeus Regex;

Eu tenho uma lista das próximas dicas que pretendo escrever sobre, essa não estava prevista, mais depois de um certo esforço para fazer isso funcionar, resolvi registrar.

Durante meu aprendizado de python conheci a htmllib, é uma biblioteca para fazer parse de documentos HTML. Antigamente eu usava regex para fazer buscas em documentos HTML, sim regex! Acredito que pior do que regex é usar o IndexOf da classe string. O problema é que regex é algo bem complicado, precisava ter um guia rápido aberto, além do mais os patterns tendem a ficar cada vez maior e mais difícil de entender. Como diria o Ramon Durães, não tem que ser difícil. De fato, não tem, a htmllib resolveu o problema, consegui de forma simples procurar tags e seus atributos usando essa super biblioteca.

De volta ao C#, me deparei com exatamente o mesmo problema. Mas dessa vez fui atrás de algo parecido e achei o SGMLReader. Pelo que andei lendo o propósito dele é converter documentos HTML em XHTML, de qualquer forma consegui novamente resolver o problema. Essa biblioteca gera uma documento XML formatado de forma perfeita, facilitando o uso do XPATH. Apenas um detalhe, ela é mais lenta que a htmlib do python, mas é bem mais flexível, você tem acesso ao XmlDocument contendo todo o código da página.

Vou deixar aqui um exemplo funcional usando essa biblioteca para resgatar todos os títulos dos posts do meu blog.

Clique aqui para fazer o download de 'SGMLReader' (92.96 kB)

Exemplo da saída do programa acima.

SGMLReader

Convite para grupo de discussão sobre arquitetura .net

Há um ano atrás a minha maior fonte para tirar dúvidas sobre arquitetura era o fórum de Arquitetura do GUJ. Apesar de ser em Java você consegue aproveitar 99% das discussões abertas, esse assunto é do tipo que você aprende uma vez e usa em qualquer lugar. Domain Model, IoC, DI, TDD, Design Patterns em geral é algo que pode ser feito qualquer linguagem, sendo ela dinâmica ou estática (não posso falar de funcional pois não sei :)). Inclusive dentro meus livros de arquitetura, a maioria deles é em Java, o Clean Code (fantástico, merece um review mais tarde) e o Code Complete (na fila…).

Para a felicidade de mais de 400 pessoas (número atual de participantes), ano passado foi criado uma lista de discussão de arquitetura focado em .Net, a idéia veio de um dos MVPs da Microsoft, o Giovanni Bassi. Aqui está a lista e aqui está o site.

Apesar do foco em .Net, temos a participação do Rafael Rosa da comunidade Ruby on Rails, o Phillip Calçado aparece de vez em quando nas threads mais quentes, e já houve a presença do Fábio Akita falando de Ruby on Rails (Vídeo).

Aproveitando o assunto, vou deixar mais alguns blogs que eu recomendo.

  1. O do Scott Hanselman, segundo esta lista com o top 200, este é o melhor blog sobre desenvolvimento desoftware;
  2. O CodeBetter, que é uma compilação de assuntos variados escritos por várias pessoas;
  3. O Bliki do Martin Fowler, preciso dizer algo? next!;
  4. Fábio Akita sobre Ruby on Rails e
  5. Phillip Calçado sobre Softwares e Batatas
http://www.hanselman.com/blog/

Dica #2: Formatando datas em formato e língua específica

Neste post do C# Brasil você consegue ver alguns dos formatos de datas possível da classe DateTime. Muitas vezes você precisa de um formato mais específico, como por exemplo, ‘Agosto, 2009′ ou ‘sábado, 29 de janeiro de 2009′.

Na lista abaixo você confere os possíveis valores de se obter usando o método ToString da classe DateTime.

Código Resultado Exemplo
HH Hora (de 0 até 23)
hh Hora (de 0 até 12)
mm Minutos
MM Mês 08, 02, 12
MMM Mês jun, ago, jan, dez
MMMM Mês agosto, setembro, outubro
dd Dia 21,10,20
ddd Dia da semana sáb, seg, ter
dddd Dia da semana sábado, segunda, terça
yy Ano 09,08,89,90
yyyy Ano 2009,2008,1989,2010

Veja alguns exemplos de como usar, e também qual o resultado.

DateTime.Now.ToString("dddd, dd 'de' MMMM 'de' yyyy"); // sábado, 22 de agostro de 2009
DateTime.Now.ToString("MMMM, yyyy"); // agostro, 2009
DateTime.Now.ToString("'dia' dd 'de' MMMM 'de' yyyy"); // dia 22 de agostro de 2009
DateTime.Now.ToString("HH:mm 'do dia' dd"); // 18:17 do dia 22
DateTime.Now.ToString("hh:mm 'do dia' dd"); // 06:17 do dia 22

Eu particularmente gosto de usar esses formatos ao invés de apenas uma letra como foi mostrado no C# Brasil, fica mais explícito e outra pessoa vai conseguir ler com mais clareza.

Por default o resultado sairá na língua atual do sistema operacional que está executando o programa, se você quer executar em uma língua específica, você pode fazer assim:

Thread.CurrentThread.CurrentCulture = new CultureInfo("nl-NL");
Console.WriteLine(DateTime.Now.ToString("dddd, MMMM")); //zaterdag, augustus

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
Console.WriteLine(DateTime.Now.ToString("dddd, dd 'de' MMMM 'de' yyyy")); //Saturday, August

Thread.CurrentThread.CurrentCulture = new CultureInfo("pt-BR");
Console.WriteLine(DateTime.Now.ToString("dddd, dd 'de' MMMM 'de' yyyy")); //sábado, agosto

Esqueci de algo?

NHibernate, por onde começar?

NHibernateA primeira vez que parei para estudar o NHibernate tive sérios problemas, decidi começar meus estudos lendo a documentação. O problema é que o projeto é desenvolvido por pessoas comuns que usam seu tempo livre para evoluir o produto, acaba que a documentação não segue o mesmo rítmo do projeto e a atualização acaba sendo deixada para outra hora. Por outro lado, existe muitos artigos e assunto sobre Hibernate (em Java), na qual pode ser aproveitado, pois seu núcleo foi apenas traduzido para .Net, o geitão de fazer as coisas é o mesmo.

Um site que eu recomendo muito para quem quer estudar o NH é o Summer of NHibernate, são 14 screenscasts sobre o assunto. É em inglês, o que pode desanimar muita gente, mas o inglês é bastante técnico, é muito mais fácil do que acompanhar um filme todo em inglês.

Os screencasts são escritos em C#, e não há interface, todos os testes são feitos usando testes automatizados, caso você não conheça, vai poder aprender dois assuntos super interessantes de uma vez só.

Antes de fazer este post, estava navegando pelo site dele e encontrei uma nova lista de screencast do mesmo autor, entitulada Autumn of Agile. Parece que ainda não foi concluído, mas pelo assunto, vale a pena ficar antenado no site (e no blog dele!).

Depois de assistir tantos screencasts (tens uns de ruby on rails vem legal aqui http://www.screencaster.com.br/), estou pensando em fazer alguns mostrando a construção de um aplicativo usando alguns frameworks disponíveis, e é claro, o NH vai ser um deles :)

Testes automatizados

A idéia por trás de usar testes automatizados é possuir uma maneira rápida de se testar uma determinada aplicação. A etapa de testes em um processo tradicional de desenvolvimento de software é feitos após a conclusão da construção e, geralmente, feito de forma manual, o problema nesse caso é que é algo excessivamente repetitivo, caro, demorado e incerto. Quando você testa alguma rotinha do sistema e verifica que ela está ok, dificilmente você vai voltar nela para re-testar, pois você presume que não vai ter problema, afinal, você já o testou. Isso é normal e muito comum, é um trabalho muito chato ter que testar todo o sistema toda vez que fizer alguma alteração.

Produtividade elevada

Produtividade elevada

Uma maneira de resolver esse problema é fazendo com que o computador teste para você, ele é muito mais rápido, barato, não torna seu trabalho repetitivo, pois não requer interferência do usuário e usando algumas métricas como Code Coverage você consegue ter uma lista de testes que te dê uma certeza do que foi e o que não foi testado.

Estes testes são escritos na forma de código fonte pelo próprio programador que escreveu a rotina a ser testado, uma técnica muito famosa nessa área é chamado de TDD que sugere que os testes sejam escritos antes do programa em si, existem vantagens significativas no uso desta prática, mas não vou entrar nesse assunto.

Outra prática muito interessante é a de Integração Contínua, onde você tem um ambiente que gera um deploy completo do seu código, executa sua suíte de testes e te deixa informado sobre os resultados. Se der certo, o produto está pronto para ser colocado em produção livre de bugs. Aqui vale uma observação, testes funcionando não significam que seu software não tem bug, mas te deixa ciente de que todos os bugs conhecidos e já testados nunca mais vão ocorrer novamente.

É comum pensar que ao utilizar testes automatizados não iremos mais precisar de uma área de testes, na minha opinião isso está errado e a área ganha ainda mais significado, ela precisa encontrar bugs, quanto mais bugs que ela encontrar, melhor. Todos esses bugs devem ser passados para a equipe de desenvolvimento que vai se responsabilizar de simular o erro usando testes automatizados, isso vai garantir que o mesmo bug nunca mais ocorra.

Quer saber mais sobre? Sugiro a leitura dos seguintes links, alguns conceituais e outros com exemplo de implementação. Se você trabalha com .Net e quiser aprender TDD, sugiro a leitura deste meu post.

Extension methods

Extension Methods

Os extensions method foram introduzidos ao .Net na versão 3.0 e são amplamente utilizados pelo Linq. Criar um método de extensão lhe traz a vantagem de poder adicionar um comportamento a qualquer tipo de objeto sem precisar alterar a definição, recompilar, criar um proxy ou uma nova classe derivada.

Exemplo de criação de um método:

namespace UsingExtMethods.MinhasClasses
{
    public static class ExtensaoString
    {
        public static int ContarEspacos(this string valor)
        {
            int qtd = 0;
            foreach (char c in valor)
                if (c == ' ')
                    qtd++;
            return qtd;
        }
    }
}

No método acima criamos uma rotinha que conta a quantidade de caracteres que há em uma string. O uso desta funcionalidade fica assim:

using System;
using UsingExtMethods.MinhasClasses;

namespace UsingExtMethods
{
    public class Program
    {
        static void Main(string[] args)
        {
            string nome = string.Empty;
            nome = "Guilherme Oenning da Silva Pereira Neto";
            Console.WriteLine(nome.ContarEspacos());
            nome = "GuilhermeOenningdaSilvaPereiraNeto";
            Console.WriteLine(nome.ContarEspacos());
            Console.ReadLine();
        }
    }
}

A Saída do programa acima será:

5
0

Quando se está desenvolvendo com o Visual Studio, é possível perceber a diferença de um método de extensão para um método normal conforme a imagem:

Extension Methods

Algumas regras quanto ao uso de Extension Methods
A classe que você quer adicionar uma funcionalidade deve ser precedida da palavra reservada this. Ex.:

public static int ContarEspacos(this string value);

Neste caso estamos criando um Método de extensão para a classe string.

O primeiro parâmetro definido não é passado na chamada do método, ele serve apenas para identificar qual a classe que recebera este novo método. Um método com a assinatura:

public static int ContarEspacos(this string value, bool considerarEspacoDuplo);

É invocado assim:

string nome = "Guilherme  Oenning";
int qtd = nome.ContarEspacos(true);

O método e a classe precisam ser obrigatóriamente declarados como static.

Para usar os métodos de extensão você precisa adicionar referência ao namespace onde foi criado a classe de extensão. Note no exemplo acima que tive que usar:

using UsingExtMethods.MinhasClasses;

Tentem remover esta linha e verão que a classe string irá perder o método ContarEspacos;
Faça um teste, crie um novo projeto Console Application. No corpo do metodo Main instancie um objeto do tipo List<string>

List<string> valores = new List<string>();

Se você olhar os métodos da variável valores usando o intellisense do Visual Studio, poderá perceber que diversos deles são métodos de extensção (blocos rosas com setas azuis), se você remover a referência ao System.Linq e novamente olhar os métodos da variável valores, claramente notará que todos eles sumiram.

Extension Methods

Por questões de organização, não misture classes que possuem definição de métodos de extensão com outras classes do sistema. Caso seja possível, prefira adicionar o método na classe. Não há motivo para inserir um método desta maneira em uma classe ao invés de abrir o código-fonte e inserí-lo diretamente na definição.

Segue alguns outros links sobre o assunto:

Livro: Test-Driven Development in Microsoft .NET

Test Driven Development in Microsoft .NETTDD é uma técnica de desenvolvimento de software onde você escreve seus testes antes de escrever o código da aplicação. Parece estranho, não? Como você vai testar algo que ainda não está pronto?

Depois de muita leitura em blogs e outros sites, eu ainda não havia conseguido achar uma resposta para esta pergunta, apelei então para um livro, e no meu caso foi o Test Driven Development in Microsoft .NET.

Eis que para minha felicidade, achei a resposta no primeiro capítulo, você escreve o teste com o intuito de ditar como vai ser o comportamento da sua aplicação, e não para ver se está funcionando. O mais interessante é que se você levar essa técnica a sério, no final do projeto você vai ter uma documentação executável e uma suite de testes automatizadas bem completa.

Além de uma introdução ao TDD, o livro fala sobre o famoso Red/Green/Refactor, customer tests e um exemplo completo de uma aplicação construída com TDD, usando ADO.NET e Web Services. Eu particularmente gostei muito do primeiro capítulo, já o segundo ficou bem cansativo de ler, há muito código nele, sem contar o uso de DataSets (não sou muito fã deles).

Essa é uma técnica que eu recomendo muito, a comunidade de Ruby on Rails faz uso constante de TDD e BDD, o que é muito legal, acho que já virou algo natural para eles. Logo mais vou falar sobre testes automatizados, que tem tudo a ver com o assunto do livro.

Dica #1: Conheça seu framework

Vou começar uma série de dicas de programação, algumas delas você já deve estar de saco cheio de ouvir ou ler, mas é sempre bom relembrar.  Meu objetivo é escrever 100 dicas, será que eu consigo?

Você sabe o que é DRY (Don’t Repeat Yourself)? É uma filosofia com um objetivo bem claro e simples para nós da computação: Reduzir a quantidade de código repetido. Uma das formas de atropelar o DRY é escrever uma função que já existe. Poxa, se já existe, você está perdendo seu tempo e adicionando complexidade desnecessária ao seu projeto. Por outro lado, uma das formas de praticar DRY é conhecer o seu framework.

Vamos para um exemplo bem comum. Quantas vezes você já encontrou algo assim:

StringBuild sql = new Stringbuild();
...
foreach (string condition in where)
{
    sql.Append(where).Append(" AND ");
}

O local mas comum é quando você tem alguma rotina que gera comandos SQL, mas já encontrei em outros lugares, como por exemplo quando você tem uma lista de tags e quer separá-las por uma vírgula ao exibir na tela. Estes dois casos poderiam ser resolvidos com uma função bem conhecida, presente em todas as plataformas de desenvolvimento, o Join.

string sql;
...
sql = String.Join(" AND ", where)

Parece uma dica boba, mas é algo que vejo com bastante frequencia.

Compilando suas views no ASP.NET MVC

Uma das vantagens em se utilizar uma linguagem compilada é que alguns erros de digitação são pegos no processo de compilação e não somente quando você executa a aplicação. No ASP.NET MVC as views não são compiladas ao fazer o build no visual studio e, portanto, estão sujeitas a ter tais erros. O problema mais comum é quando você faz um Refactor -> Rename em uma de suas classes, o visual studio NÃO vai renomear essas classes em suas views, e você só vai notar o erro quando estiver nagendo na página. Para que o visual studio compile suas views, e consequentemente, resolva o problema citado, siga os passos:

  1. Com o notepad, abra o arquivo *.csproj ou *.vbproj da sua aplicação MVC.
  2. Procure a tag <PropertyGroup> e antes de fechá-la (</PropertyGroup>), adicione o seguinte conteúdo: <MvcBuildViews>true</MvcBuildViews>.

Existem várias tags PropertyGroup e cada uma deles corresponde a uma configuração de build dentro do visual studio (Debug/Release), utilize aquela que você achar melhor ou então insira dentro de todas elas. Feito isso, os problemas encontrados serão listados na aba Error List.

So far, so good

Compiling!

Só tem um porém, você vai sentir um enorme delay no build, o tempo de compilação quase triplica.

Quando se está trabalhando em um projeto pequeno não fará tanta diferença, agora quando seu projeto for muito grande, você pode optar por esperar enquanto toma um café, brincar de “lutinha” com seu amigo de trabalho ou pedir para seu chefe um servidor de integração contínua.

No caso de optar pela última opção (a melhor delas, mesmo gostando da segunda), você pode deixar para compilar suas views uma vez por dia caso demore muito.

É importante lembrar que uma aplicação compilada não significa que está funcionando, a melhor maneira de saber é rodando testes automatizados, logo TATFT.

Sharing Buttons by Linksku