Fred Policarpo - Desenvolvimento de Software

.NET Open Day (Itumbiara - 30/09/2009)

2009-10-01T07:59:00.000-07:00

O evento .NET Open Day superou minhas expectativas! O pessoal participou em peso, muita gente mesmo.

A primeira boa impressão que tive foi a receptividade do pessoal do curso de Sistema de Informação, eles realmente foram muito gentis conosco (Marcos e eu). A simpatia, sem dúvidas, é uma ferramenta importantíssima para um bom networking.

A segunda surpresa foi o número de pessoas no auditório, que estava muito cheio, praticamente lotado. O Gesmar até tinha me falado do grande interresse do pessoal, mas de certa forma eu estava receoso quanto à empolgação da qual ele falou.

Esse interesse dos alunos é de suma importância para o crescimento profissional dos mesmos, Além do mais, essas oportunidades que surgem na faculdade tem de ser agarradas com força, pois pode ser que na vida de profissional seja um pouco mais difícil de participar delas.

Durante a palestra do Gesmar tive conhecimento de outra coisa que me deixou bastante satisfeito: o número de pessoas que está participando da célula atualmente. A lista realmente é grande. Deixo meu total incentivo para que continuem com força total nas atividades, e faço questão de dar uma forcinha sempre que possível. Escrevam muito código pois programar se aprende pogramando.

Durante minhas palestras, primeiro de Windows Workflow Foundation e depois de Silverlight, gostei de ver que o pessoal manteve boa atenção em tudo que eu estava passando, mesmo sendo um assunto técnico e às vezes confuso para alguns. Além do mais notei que poucas pessoas sairam do auditório durante todo evento, o que também considero um ótimo resultado.

E para fechar a noite fomos pra um bar local, o Academia do Chopp, para fazer uma confraternização onde falamos de .NET, mercado de trabalho, futebol e atitude!

Foi uma ótima experiência, espero voltar a Itumbiara para realizar outras atividades com o pessoal da Ulbra.

O material já está disponível, em breve fotos e videos.

Abraços,

Fred Policarpo
MCP - Microsoft Certified Professional
MCTS: .NET Framework 2.0 Windows Applications
MCTS: .NET Framework 3.5 Windows Presentation Foundation Applications
MCTS: .NET Framework 3.5 Windows Workflow Foundation Applications
Consultor/Desenvolvedor - Fibonacci Soluções Ágeis - http://fibonacci.inf.br

Treinamento Framework.NET - Tron Informática

2009-09-10T14:05:00.000-07:00

Na terça-feira passada (08/09/2009) finalizei o treinamento sobre o Framework.NET da Tron Informática. O treinamento, que teve duração de uma semana, pois iniciou-se dia 01/09/2009, foi ministrado a três equipes: desenvolvimento, manutenção e homologação.

Antes de mais nada é necessário explicar do que estou falando! O Framework.NET em questão é um software que foi desenvolvido pela Tron Informática em parceria com a Fibonacci - Soluções Ágeis, durante um contrato de consultoria em arquitetura de software solicitado pela Tron. Essa consultoria, que teve duração de quatro meses, teve como objetivo a preparação de um framework para desenvolvimento de aplicações web com .NET 3.5, que será a tecnologia usada para construção dos novos produtos da Tron. Essa consultoria foi aplicada por mim(Fred Policarpo) e pelo Márcio Siqueira (sócio/diretor da Fibonacci). O representante do cliente foi o Weverton Gomes.

Agora que já sabemos que o Framework.NET, produto da Tron, não é a mesma coisa que o .NET Framework, produto da Microsoft, posso continuar a falar sobre o treinamento.

Durante esses cinco dias de aula tivemos grande foco em explicar a importância do Desenvolvimento Orientado a Testes (TDD), da Orientação a Objetos (OO), das responsabilidades de cada camada das aplicações que serão construídas tendo como base esse framework, e também das facilidades que o mesmo irá proporcionar aos usuários(códigos reutilisáveis, diversas funcionalidades comuns às aplicações já disponíveis, além de uma ferramenta de automatização para acelerar ainda mais o desenvolvimento)

Foi muito produtivo ter trabalhado durante esses quatro meses com o que há de mais recente no mundo .NET (como LINQ, WCF e Silverlight 3) assim como foi excelente ter a oportunidade de passar um pouco desse conhecimento para as equipes que irão trabalhar com esse framework.

Mudanças de conceito são sempre um passo difícil para a maioria das pessoas, e eu me incluo nesse conjunto. Mesmo assim, percebi uma vontade de aprender dos profissionais que lá estavam e acredito que, com a decicação e paciência adequada, eles irão se adaptar e confirmar a melhoria de produtividade e qualidade que o Framework.NET irá oferecer aos produtos a serem desenvolvidos.

Deixo então meu agradecimento à Fibonacci - Solulções Ágeis por ter confiado meu trabalho neste projeto, à Tron Informática por ter confiado essa responsabilidade à Fibonacci e à mim(que sou apenas um jovem desenvolvedor), ao Weverton por ter tido paciência com as questões que eu também desconhecia e que tivemos que aprender juntos, e ao pessoal que acompanhou o treinamento e conseguiu manter a atenção e dedicação apesar do horário puxado. Obrigado a todos.

Às empresas que tiverem interesse, a Fibonacci possui uma equipe de arquitetos prontos para dar treinamento e consultoria em arquitetura\desenvolvimento de software(.NET, Grails, Ruby on Rails, Java) e também em metodologias ágeis.

Abraços,

Fred Policarpo
MCP - Microsoft Certified Professional
MCTS: .NET Framework 2.0 Windows Applications
MCTS: .NET Framework 3.5 Windows Presentation Foundation Applications
MCTS: .NET Framework 3.5 Windows Workflow Foundation Applications
Consultor/Desenvolvedor - Fibonacci Soluções Ágeis - http://fibonacci.inf.br

Como matar uma palestra

2009-08-26T04:06:00.000-07:00

Ontem fui a uma palestra sobre testes e qualidade de software, marcada para as 19hs de uma terça-feira comum. Para quem trabalha o dia todo, nada melhor do que uma palestra que será depois do expediente, ainda mais de graça, como foi essa em questão.

O tema então é excelente, pelo menos eu estou de acordo que testes e qualidade de software são assuntos de suma importância para o sucesso de sistema de computador, ou de qualquer sistema.

Porém nem tudo na vida são flores, a começar com um atraso de 50 minutos. É isso mesmo, quase uma hora!

Então vamos à primeira coisa que mata uma palestra:

Atraso maior do que 15 minutos

Esse problema pode não ser culpa direta do palestrante e sim da organização, porém o fato de ser em um dia de semana, onde a grande maioria das pessoas passou por uma jornada cansativa de oito, ou mais, horas de trabalho, é extremamente desconfortável um atraso tão grande.

Segundo tiro no pé:

Falta de objetividade

Novamente o fato de ser em um dia de semana faz com que algumas atitudes tornem a palestra muito cansativa.

Para essa palestra o público era seleto, estudantes, professores, profissionais e empresários.

Considerando esse público, o palestrante não precisa de 3 minutos para explicar que um código com 1000 linhas de código é mais complexo do que um com 10 linhas de código, e muito menos de 10 minutos para explicar que na realidade as empresas corrigem os erros e não os previnem. Essas duas coisas poderiam ser ditas em apenas um minuto, seria melhor para todos se fosse assim. Esses devaneios vão consumindo a paciência do público, a minha então já estava ficando com saldo negativo.

Terceira atitude negativa:

Comparar engenharia de software com engenharia civil, programadores com pedreiros

Já não é de hoje que existem pesquisas e mais pesquisas mostrando que um dos maiores erros da indústria de software é tentar seguir o modelo das fábricas tradicionais, o Taylorismo, e seguir os passos das engenharias tradicionais: cívil, automobilística, etc.. No mundo do software o pedreiro é o compilador, será difícil, para uma pessoa com tantos anos de experiência, entender isso?

Insistir nessa comparação ilógica é como se alguém insistisse que é melhor usar a linguagem C para desenvolver sistemas de informação para Web do que usar .NET, Java, Grails ou Ruby On Rails.

Como palestrante eu ainda não tenho experiência, mas como ouvinte eu posso dar minha opinião sobre o que atrai ou não a atenção da platéia, e está dito!

Abraços,

Fred Policarpo
MCP - Microsoft Certified Professional
MCTS: .NET Framework 2.0 Windows Applications
MCTS: .NET Framework 3.5 Windows Presentation Foundation Applications
MCTS: .NET Framework 3.5 Windows Workflow Foundation Applications
Consultor/Desenvolvedor - Fibonacci Soluções Ágeis - http://solucoesageis.com.br

Obtendo todas actions de um serviço WCF

2009-08-11T08:26:00.000-07:00

Quando se trabalha com WCF você precisa de uma interface que irá definir o contrato do serviço a ser disponibilizado com esta tecnologia.

Essa interface deve ser marcada com o atributo ServiceContract, e cada método desta interface que deverá estar disponível pelo serviço deve ser marcado com o atributo OperationContract.

Se você estiver muito confuso sobre o que falei até o momento aconselho que dê uma lida neste artigo de introdução aos serviços em WCF: Introdução ao WCF.

O atributo OperationContract contém uma série de proriedades, uma delas é a Action (detalhes).

A propriedade Action é usada para identificar de forma única a operação equivalente. No projeto em que estou trabalhando aparece a necessidade se determinar, em tempo de execução, qual a lista completa de actions das operações disponíveis em um dado contrato de serviço (a interface). Após algumas análises conseguimos o seguinte código que, via reflexão, nos retorna uma lista de strings com todas actions de um dado serviço:

public static IList ObtenhaTodasOperacoes()
{
    var actions = new List();
    foreach (var method in typeof(T).GetMethods())
    {
        var att = (OperationContractAttribute)Attribute.GetCustomAttribute(method, typeof(OperationContractAttribute));
        if (att != null) actions.Add(att.Action);
    }

    return actions;
}

Na verdade a implementação está mais relacionada a Reflections do que a WCF, porém é uma utilidade que os usuários de WCF podem precisar no decorrer de seu projeto.

É isso,

Abraços,

Fred Policarpo
MCP - Microsoft Certified Professional
MCTS: .NET Framework 2.0 Windows Applications
MCTS: .NET Framework 3.5 Windows Presentation Foundation Applications
MCTS: .NET Framework 3.5 Windows Workflow Foundation Applications
Consultor em Arquitetura de Software na Fibonacci Soluções Ágeis - http://solucoesageis.com.br

Aula na Fibonacci - TDD + Singleton

2009-07-27T17:58:00.000-07:00

Conforme foi dito no post anterior, eu estava planejando uma aula para os dedicados alunos da Célula .NET da Faculdade Objetivo. Tudo deu certo e essa aula realmente aconteceu no dia 25/07/2009 em uma das salas de desenvolvimento da Fibonacci - Soluções Ágeis.

O tempo foi muito curto para tudo que eu gostaria de passar para o pessoal, não por culpa do tempo, mas por culpa da minha imensa vontade de passar o máximo de informações importantes para eles. Porém não adianta ter pressa, a coisa precisa ser bem feita antes de mais nada, por isso mesmo focamos em dois assuntos principais: TDD e o Padrão Singleton.

Os outros assuntos mercem uma aula dedicada cada um, são eles: Reflection, Padrão Factory, Configuração, Convensão sobre Configuração e Generics. Ufa é muita coisa para uma manhã só mesmo. Outras manhãs virão e esses assuntos ainda serão focados ;-P

Agradeço ao Rogério, à Ana Paula e ao Marcos pela persença. Continuem se esforçando, e principalmente escrevendo muito código! Agradeço também à Fibonacci - Soluções Ágeis que cedeu o espaço e os equipamentos.

Abaixo seguem a fotos, de qualidade duvidosa, da nossa primeira aula e também o link para obter os slides usados na mesma.

Um grande abraço e até breve.

Fred Policarpo

MCP - Microsoft Certified Professional
MCTS: .NET Framework 2.0 Windows Applications
MCTS: .NET Framework 3.5 Windows Presentation Foundation Applications
MCTS: .NET Framework 3.5 Windows Workflow Foundation Applications
Consultor em Arquitetura de Software na Fibonacci Soluções Ágeis - http://fibonacci.inf.br/

Baixar Material

Aula sobre Padrões Criacionais com C# 3.5

2009-07-23T08:28:00.000-07:00

Neste sábado, dia 25/07/2009, ministrarei uma aula sobre três padrões criacionais da Gange dos Quatro (GoF), são eles:

Abstract Factory
Factory Method
Singleton

O foco deste estudo não é apenas os padrões em si, que são simples de compreender, também será enfatizada a técnica de TDD (Test Driven Devlopment). Da parte do .NET Framework serão focados os seguintes tópicos:

Reflexão
Configurações (App.Config)
Generics

O estudo será realizado utilizando a linguagem C# 3.5 com o Visual Studio 2008. Esta é uma parceira minha (Fred Policarpo) com o pessoal da Célula Acadêmica .NET da Faculdade Objetivo (Goiânia - GO) com apoio da Fibonacci - Soluções Ágeis, que irá fornecer toda infraestrutura para esta aula.

Caso você não seja desta célula e deseje participar mande-me uma direct message no Twitter para que eu possa checar se ainda há vagas.

Abraços,

Fred Policarpo
MCP - Microsoft Certified Professional
MCTS: .NET Framework 2.0 Windows Applications
MCTS: .NET Framework 3.5 Windows Presentation Foundation Applications
MCTS: .NET Framework 3.5 Windows Workflow Foundation Applications
Consultor em Arquitetura de Software na Fibonacci Soluções Ágeis - http://solucoesageis.com.br

Programação em Par vs Revisão de Código

2009-07-09T08:24:00.000-07:00

Enquanto o Extreming Programming(XP) tem como uma das suas práticas a programação em par, o Scrum utiliza a revisão de código. Quais das duas usar em seu projeto ? Qual é a melhor estratégia ?

Se você já tiver uma pequena noção sobre metodologias ágeis sabe que não existe uma resposta universal para as perguntas acima, a resposta certa é "depende". Obviamente se eu faço essas perguntas, dou essa resposta e então finalizo o post, tenho certeza de que perderei muitos leitores.

O objetivo deste texo é explicar algumas vantagens e desvantagens de cada uma dessas estratégias, quando e por que utilizá-las, além de mostrar a estratégia adotada com a equipe do projeto FPw Workflow (produto da LG Sistemas desenvolvido e mantido pela Fibonacci - Soluções Ágeis), no qual trabalhei por um ano e meio como Coach.

Programação em Par (XP)

A programação em par é, a principio, a estratégia mais cara, pois com ela é preciso manter dois desenvolvedores trabalhando na mesma estória. Porém, dessa forma, o código recebe revisão em tempo real, cada desenvolvedor monitora o código que o outro está escrevendo, o tempo todo, de forma a identificar erros comuns de programação de forma imediata, e então minimizar o custo de correção dos mesmos.

No final das contas a programação em par pode se tornar mais barata, já que irão "vazar" bem menos erros do que vazaria se uma pessoa estivesse programando sozinha, além disso o código fica mais legível já que será necessário a compreensão de duas pessoas e não de uma só.

Pergunta: Bem, se o a programação em par traz tantos benefícios por não utilizá-la sempre ?

Resposta: Quando as diferenças no níveis de conhecimento dos programadores de uma equipe possuir uma grande amplitude. Trocando em miúdos, se você coloca um programdor Senior para trabalhar em par com um programador estagiário sem nenhuma experiência, há uma grande chance de o Senior fazer todo o trabalho e o estagiário ficar olhando, pois não conseguirá acompanhar o desenvolvimento do outro, que por motivos de prazo e ansiedade, nem sempre terá a paciência para explicar tudo o que o outro não compreender.

Revisão de Código (Scrum)

O Scrum sugere que o código de uma dada feature seja revisado por outros desenvolvedores antes que possa ser considerado como concluído.

A princípio essa prática é mais barata pois só será necessário concentrar o trabalho de mais de um desenvolvedor em uma feature no momento da revisão de código, e esse momento é muito curto em relação a todo tempo necessário para a implementação da mesma.

Pergunta: Bem, se a revisão de código é barata, e no final o código será revisado por vários desenvolvedores, por que não utilizá-la sempre ?

Resposta: Durante o desenvolvimento de uma feature existem pontos críticos nos quais o trabalho em par se mostra muito mais eficiente do que trabalhar sozinho, de forma que trabalhar sozinho todo tempo pode atrasar o desenvolvimento além de impedir que a qualidade do código seja melhor, caso fosse escrito por mais de uma pessoa.

Caso Real: O melhor dos dois mundos no projeto FPw Workflow (LG Sistemas)

Na equipe de desenvolvimento do projeto FPw Workflow adotamos a seguinte estratégia para lidar tanto com as vantagens da programação em par quanto da revisão de código, e consequentemente minimizar as desvantagens das mesmas. A estratégia é exemplificada com a lista abaixo:

No início de qualquer feature o desenvolvimento deve ser em par, com o responsável pela feature e o coach da equipe, até que solução já tenha um esboço inicial palpável(esse ponto varia de acordo com a experiência do desenvolvedor);
O desenvolvedor deve reconhecer pontos, durante o desenvolvimento, de maior impacto no código e na arquitetura do sistema, e então solicitar o coach para escolherem a melhor estratégia;
O restante do desenvolvimento o responsável realiza sozinho;
Quando o responsável der a feature por concluída, o coach faz a revisão de código e se necessário deve solicitar a participação de outra pessoa da equipe com mais experiência.

É isso, essa estratégia antendeu melhor nossas necessidades do que a adoção isolada da pogramação em par ou revisão de código, e só chegamos nessa fórmula tentando, errando e corrigindo, ou seja aplicando o processo auto-adaptativo.

Espero ter contribuído!

Links:
http://www.lg.com.br/
http://fibonacci.inf.br/
http://improveit.com.br/xp/praticas/programacao_par

ExpectedException para NUnit 2.5

2009-07-06T10:03:00.000-07:00

Uma mudança na versão 2.5 do NUnit é a forma de se indicar que um dado código de teste deve levantar uma exceção.

Nas versões anteriores à versão 2.5 isso era feito atravéz do atributo [ExpectedException], aplicado ao método que contem seu teste, como no exemplo abaixo:


      [Test]
      [ExpectedException(typeof(NullReferenceException))]
      public void TesteAcessoObjetoNulo()
      {
              MeuObjeto obj = null;
              obj.MeuMetodo();
      }

A partir da versão 2.5 o atributo [ExpectedException] deve ser substituido pelo método estático Assert.Throws. Como no exemplo abaixo:


       [Test]       
       public void TesteAcessoObjetoNulo()
       {
               MeuObjeto obj = null;
               Assert.Throws<NullReferenceException>(() => obj.MeuMetodo());
       }

É só isso, não tem mais nada, acabou, boa sorte... :-P

Abraços

Programação Assíncrona [Parte 2 - BackgroundWorker]

2008-06-22T16:55:00.000-07:00

Em .NET existe um componente que provê uma forma bastante simplificada de se realizar as diversas operações necessárias para se executar código de forma assíncrona:

Exibir o progresso da operação;
Obter o resultado na thread que iniciou a execução assíncrona;
Cancelar a operação;
Monitorar o estado da operação.

Este componente é o BackgroundWorker (System.ComponentModel.BackgroundWorkder).

Para aplicações WindowsForms adicionar este componente é tão simles quanto realizar um drag and drop do mesmo na parte Components da Toolbox do Visual Studio, para as demais aplicações

é necessário declarar e instanciar um objeto BackgroundWorker, o que é também um trabalho trivial.

Um vez que temos um BackgroundWorker em mãos vamos ao que nos interessa. Primeiramente vamos supor que o código que desejamos executar de forma assíncrona é o representado pelo método BaixeArquivos, abaixo:

private void BaixeArquivos(string[] urls)

{

foreach (string url in urls)

{

BaixeArquivos(url, DiretorioDeDestino);

}

Obs.: Considere também que BaixeArquivo é um método que realmente realiza o download de um dado arquivo, com base na url do mesmo, e que DiretorioDeDestino é uma constante da aplicação.

Para que este código seja executado via BackgroundWorker é necessário invoca-lo de dentro do evento DoWork:

BackgroundWorker worker = new BackgroundWorker(); // variável de instância

void AlgumMetodo()

{

//codigo qualquer

worker.DoWork += (Worker_DoWork);

worker.RunWorkerAsync(

new string[]

{

"http://solucoesageis.com.br/Portals/0/logoNFe.JPG",

"http://www.google.com.br/intl/pt-BR_br/images/logo.gif",

"http://www.msdnbrasil.com.br/anp/img/tit_ranking_msdn.gif"

});

//codigo qualquer

}

void Worker_DoWork(object sender, DoWorkEventArgs e)

{

BaixeArquivos(e.Argument as string[]);

}

O código acima já ilustra duas operações do componente em questão: a criação do método que irá executar de forma assíncrona(assinar o evento DoWork) e o disparo da operação (invocar o método RunWorkerAsync). Note que os argumentos necessários para a execução da operação são passados atravéz do argumento do método RunWorkerAsync, que é do tipo object, e depois deve ser convertido para o tipo apropriado dentro do código que executa a operação.

Neste ponto já sabemos criar um BackgroundWorker, assinar o seu evento principal fornecer os argumentos necessários, iniciar a operação, obter os argumentos(via DoWorkEventArgs.Argument) e realizar o trabalho necessário. Para situções mais simples isso já é o suficiente, porém se o caso for esse aconselho o uso de delegates, pois se trata do caso mais simples de execução assíncrona.

Então o que mais pode ser necesário ??

Relatar Progresso: para relatar progresso é necessário assinar o evento ProgressChanged e invocar o método ReportProgress. Veja a aplicação desta estratégia em nosso estudo de caso:

void AlgumMetodo()

{

//codigo qualquer

worker.DoWork += (Worker_DoWork);

worker.ProgressChanged += (Worker_ProgressChanged);

worker.RunWorkerAsync(

new string[]

{

"http://solucoesageis.com.br/Portals/0/logoNFe.JPG",

"http://www.google.com.br/intl/pt-BR_br/images/logo.gif",

"http://www.msdnbrasil.com.br/anp/img/tit_ranking_msdn.gif"

});

//codigo qualquer

}

void Worker_ProgressChanged(object sender, ProgressChangedEventArgs e)

{

Console.Write("Operação " + e.ProgressPercentage + "% concluída.");

}

private void BaixeArquivos(string[] urls)

{

int cont = 0;

foreach (string url in urls)

{

BaixeArquivos(url, DiretorioDeDestino);

worker.ReportProgress((++cont)/urls.Length);

}

Veja que o método que relata o progresso é o que assina o evento ProgressChanged e que o método ReportProgess deve ser invocado de dentro do código que é executado assíncronamente, pois este deve saber em qual porcentagem de conclusão ele se encontra.

Outro detalhe é a propriedade WorkerReportsProgress que indica se o componente irá invocar o evento ProgressChanged quando o método ReportProgress for chamado, o valor dessa propriedade é true por default.

Pronto agora já sabemos como relatar progresso, o controle ProgressBar poderia ser usado no lugar da escrita no Console para aplicações WindowsForms. Então vamos à próxima necessidade:

Cancelar a operação: para cancelar uma operação que foi iniciada por um BackgroundWorker é necessário invocar o método CancelAsync que irá disparar o evento RunWorkerCompleted. Quando este método é invocado o propriedade CancellationPending é configurada com true, e então o valor dessa variável deve ser verificado dentro do método que assina o evento DoWork para que neste a lógica de cancelamento seja executada. Assim como no relatório de progresso você tem a opção de desabilitar o cancelamento da operação atravéz da porpriedade WorkerSuportsCancellation, que é true por default. Veja a ilustração de um cancelameno abaixo:

void AlgumMetodo()

{

//codigo qualquer

worker.DoWork += (Worker_DoWork);

worker.ProgressChanged += (Worker_ProgressChanged);

worker.RunWorkerCompleted += (Worker_RunWorkerCompleted);

worker.RunWorkerAsync(

new string[]

{

"http://solucoesageis.com.br/Portals/0/logoNFe.JPG",

"http://www.google.com.br/intl/pt-BR_br/images/logo.gif",

"http://www.msdnbrasil.com.br/anp/img/tit_ranking_msdn.gif"

});

//codigo qualquer

}

private void VerificaSeEhNecessarioCancelar()

{

// Verificou-se que é necessário cancelar

worker.CancelAsync();

}

void Worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)

{

if (e.Cancelled)

Console.WriteLine("Operação cancelada");

}

private void BaixeArquivos(string[] urls)

{

int cont = 0;

foreach (string url in urls)

{

if (worker.CancellationPending)

{

// Possível lógica de cancelamento deve estar aqui

e.Cancel = true;

return;

}

BaixeArquivos(url, DiretorioDeDestino);

worker.ReportProgress((++cont)/urls.Length);

}

Observe que a lógica de cancelamento deve ser inserida no código que está sendo executado de forma assíncrona. Além disso note que evento para este caso é o evento de conclusão da operação, isto é, ele será invocado não só apenas quando houver cancelamento da operação, e sim sempre que esta for conlcuída, independentemente do resultado. Com base nisto vamos para o próximo requisito:

Obter o resultado da operação: como você já sabe assinar o evento que será disparado no momento de conclusão da operação resta apenas um detalhe: indicar o resultado, isto é feito atravéz da propriedade DoWorkEventArgs.Result. Como a propriedade Result só pode ser obtida de dentro do método que assina o evento DoWork teremos que migrar o código do método BaixeArquivos para dentro do método Workder_DoWork (claro que existem outras formas de se fazer isto, mas vamos simplificar). Vamos ao código:

void Worker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)

{

if (e.Cancelled)

Console.WriteLine("Operação cancelada");

else

Console.WriteLine("Resultado: " + e.Result);

}

void Worker_DoWork(object sender, DoWorkEventArgs e)

{

string urls = e.Argument as string[];

int cont = 0;

foreach (string url in urls)

{

if (worker.CancellationPending)

{

// Possível lógica de cancelamento deve estar aqui

e.Cancel = true;

return;

}

BaixeArquivos(url, DiretorioDeDestino);

worker.ReportProgress((++cont)/urls.Length);

}

e.Result = "Downalods Realizados";

}

A propriedade Result é do tipo Object, o que permite que qualquer tipo de resultado seja retornado atravéz dela.

A última manipulação que será explicada é a consulta do status de uma operação assíncrona.

Requisitando o status de uma operação: Em algum momento de seu código pode ser necessário saber se a operação está acontecendo, ou se ela já está concluída (pois nem sempre o resultado da mesma será retornado), resumindo, pode ser necessário saber se o componente BackgroundWorker está trabalhando ou se ele está livre. Exemplo: para poder iniciar uma nova operação, no caso desta operação não poder ser executada mais de uma vez ao mesmo tempo. Para saber isso é preciso consultar a propriedade IsBusy do BackgroundWorker. Código:

private void TenteLancarOperacao()

{

if (!worker.IsBusy)

{

worker.RunWorkerAsync(

new string[]

{

"http://solucoesageis.com.br/Portals/0/logoNFe.JPG",

"http://www.google.com.br/intl/pt-BR_br/images/logo.gif",

"http://www.msdnbrasil.com.br/anp/img/tit_ranking_msdn.gif"

});

}

Espero que neste ponto você considere um novo componente para sua caixa de ferramentas de programação. Existem mil formas de se fazer a mesma coisa, e tudo indica que devemos dar preferência para o caminho mais curto e o BackgroundWorker é um caminho curto para operações assíncronas onde é necessário um acompanhamento minucioso do processo, pois neste a parte burocrática já está pronta, basta inserir o código certo no local certo.

Até o próximo post!

Executando métodos de forma assíncrona [Parte1 - Delegates]

2008-05-29T18:23:00.000-07:00

Programação assíncrona é um assunto bastante completo e complexo. Um dos motivos para ser assim é que existem diversas formas para se executar código assincronamente, isto é, em uma thread separada. As principais estratégias são:

Usar a classe Thread;
Usar o componente BackgroundWorker;
Usar delegates;

Neste artigo vou falar da forma mais rápida de se executar um trecho de código em um thread separada e dedicada: através de delegates.

Existem três estratégias para executar código em uma thread dedicada, são eles:

Chame o método assíncronamente, faça alguma coisa e finalize a chamada assíncrona (a thread fica bloqueada até a o término da operação)
Chame o método assíncronamente, e enquanto a execução não terminar faça alguma coisa, e então finalize a chamada assíncrona.
Chame o método assínconamente, defina um CallBack para ser invocado no final da operação assíncorna, na implementação do CallBack finalize a chamada assíncrona.

A primeira coisa a se fazer é criar um delegate com a mesma assinatura do método que contém o código que se deseja executar assincronamente. Veja o exemplo:

Método:

public string BuscaDocumento(string autor, int posicao)

{

string caminho = string.Empty;

// faz alguma coisa

return caminho;

}

Delegate:

public delegate string BuscaDocumentoDelegate(string autor, int posicao);

Neste ponto já podemos realizar duas das estratégias de programação assíncrona usando delegates:

Chame o método assíncronamente, faça alguma coisa e finalize a chamada assíncrona (a thread fica bloqueada até a o término da operação)
Chame o método assíncronamente, e enquanto a execução não terminar faça alguma coisa, e então finalize a chamada assíncrona.

Vamos aos usos:

Caso 01: Chame o método assíncronamente, faça alguma coisa e finalize a chamada assíncrona (a thread fica bloqueada até a o término da operação)

BuscaDocumentoDelegate buscaDel = BuscaDocumento;

IAsyncResult result = buscaDel.BeginInvoke("Erico Veríssimo", 25, null, null);

//faça alguma coisa outra coisa

string resultado = buscaDel.EndInvoke(result); /* a thread bloqueia nesse ponto até que a operação BuscaDocumento seja concluida */

obs:

Os dois parâmetros nulos na chamada do método BeginInvoke são CallBack e State, respectivamente. Estes são necessários apenas para a terceira estratégia, a qual será demonstrada ainda neste artigo.

Caso 02: Chame o método assíncronamente, e enquanto a execução não terminar faça alguma coisa, e então finalize a chamada assíncrona.

BuscaDocumentoDelegate buscaDel = BuscaDocumento;

IAsyncResult result = buscaDel.BeginInvoke("Erico Veríssimo", 25, null, null);

while (!result.IsCompleted)

{

//faça qualquer coisa

}

string resultado = buscaDel.EndInvoke(result);

A vantagem desta implementação em relação às demais é que a thread principal não ficará bloqueada enquanto a thread em backgound não for concluída, o que permite que trechos de código sejam executados até a finalização da operação inciada via delegate.

A terceira forma é através de CallBacks, esta exige a implementação de outro método e será explicada a seguir.

Além do método com o código e do delegate equivalente é necessário um método de CallBack, que será invocado quando a operação assíncrona for concluída. O CallBack deve retornar void e receber um IasyncResult como argumento.

Método de CallBack:

public void BuscaDocumentoCallBack(IAsyncResult resultado)

{

BuscaDocumentoDelegate buscaDel = (BuscaDocumentoDelegate) resultado.AsyncState ;

string resultadoDaBusca = buscaDel.EndInvoke(resultado);

Console.WriteLine("Resultado da Busca: {0}", resultadoDaBusca);

}

Usando o delegate:

BuscaDocumentoDelegate buscaDel = BuscaDocumento;

buscaDel.BeginInvoke("Arnaldo Jabor", 34, BuscaDocumentoCallBack, buscaDel);

/* O fluxo desta thread continua, de modo que outras operações podem ser realizadas enquanto a operação em background prossegue, e quando esta finalizar o método BuscaDocumentoCallBack será invocado. */

Como podem ver não tem segredo. Essas técnicas são muito úteis em programas Windows Forms, pois nestes geralmente o usuário precisa de executar várias operações ao mesmo tempo, e além disso também são útis para processamentos longos que não necessitam de retorno imediato.

Em breve volto com Threads e BackgroundWorker!

Abraços,

Até

Biblioteca de Expressões Regulares[Regex Library]

2008-05-16T09:15:00.000-07:00

Os modelos de programação modernos tem se preocupado principalmente com princípios de alto-nível como robustez, flexibilidade, boa arquitetura e um projeto composto de módulos com baixo acoplamento e alta coesão. E eu estou de total acordo com eles, são esses princípios que sustentam grandes softwares, principalmente aqueles que necessitam de constante alteração (isto é, 99%* deles :-))

Porém existem cenários em que habilidades que antes eram extremamente comuns para os programadores vôvôs, de sistemas Unix e tal, e que para nós, engenheiros de software, não são tão intuitivas, se tornam a chave para uma boa solução. Um exemplo disso são as Expressões Regulares, cujo cenário em que dominam é o reconhecimento de padrões em textos.

Por exemplo: Como fazer para verificar se uma string é uma data válida ? As duas opções que vejo são:

Um código cheio de IFs e extremamente confuso

Um expressão regular, não menos confusa que a opção anterior :-p

A grande vantagem da expressão regular é o desempenho, as bibliotecas que processam essas expressões são altamente eficientes, a classe Regex de .NET, por exemplo.

A grande dificuldade de expressões regulares é complexidade, veja por exemplo a expressão regular para validar data no formato dd/mm/aaaa:

(((0[1-9]|[12][0-9]|3[01])([/])(0[13578]|10|12)([/])(\d{4}))|
(([0][1-9]|[12][0-9]|30)([/])(0[469]|11)([/])(\d{4}))|
((0[1-9]|1[0-9]|2[0-8])([/])(02)([/])(\d{4}))|
((29)(\.|-|\/)(02)([/])([02468][048]00))|
((29)([/])(02)([/])([13579][26]00))|((29)([/])(02)([/])([0-9][0-9][0][48]))|
((29)([/])(02)([/])([0-9][0-9][2468][048]))|
((29)([/])(02)([/])([0-9][0-9][13579][26])))

Simples né ??

Mas o interessante é que encontrei um site com centenas dessas expressões malucas: http://regexlib.com/

Com essa ferramenta (o site) você pode facilitar a grande dor de cabeça das expressões regulares, isto é, a confecção das mesmas, e então aproveitar do que elas tem de melhor: Eficiência!

Dica .NET

Para fazer a validação de data (dd/mm/aaaa) em .NET (C#) use o seguinte código:

bool regex(string data)

{

string expressao = @"(((0[1-9]|[12][0-9]|3[01])([/])(0[13578]|10|12)([/])(\d{4}))|

(([0][1-9]|[12][0-9]|30)([/])(0[469]|11)([/])(\d{4}))|

((0[1-9]|1[0-9]|2[0-8])([/])(02)([/])(\d{4}))|((29)(\.|-|\/)(02)([/])([02468][048]00))|

((29)([/])(02)([/])([13579][26]00))|

((29)([/])(02)([/])([0-9][0-9][0][48]))|

((29)([/])(02)([/])([0-9][0-9][2468][048]))|

((29)([/])(02)([/])([0-9][0-9][13579][26])))";

return Regex.IsMatch(data, expressao);

}

O recado é esse, se precisar de Expressões Regulares, prontinhas e esperando para serem usadas, acesse:

* Esses 99% foi um número inventado por mim mesmo, mas caso você pesquise verá que realmente se trata da grande maioria.

Coleções Case-Insensitive [Parte 02 - Busca em ArrayList]

2008-05-16T09:06:00.000-07:00

Neste artigo vou falar um pouco de como trabalhar com Case-Insensitive em Listas, como havia combinado no artigo anterior.

Antes de falar de lista gostaria de falar de um tipo de Hashtable (eu sei que Hashtable foi assunto do outro post, porém existe uma armadilha do .NET :-) )

Conforme apresentei anteriormente, a classe usada para criar Hashtable Case-Insensitive é CollectionsUtil, com o método CollectionsUtil.CreateCaseInsensitiveHashtable().

O outro método utilitário desta classe é CollectionsUtil.CreateCaseInsensitiveSortedList(). Então ele é o usado para lista case insensitive ?? Não, ele é usado para criar um SortedList que na verdade é um Hashtable e que ordena as entradas pelo valor das chaves :S Estranho, não!? Esse nome realmente não é sugestivo, pois não se trata de uma lista ordenada, mas SortedList é assunto para outro post, vamos ao que interessa!

Pra começar é interessante notar que Case-Insensitive é um problema natural de dicionários, e não de listas, e deve ser por isso que não existe um lista nativa em .NET que seja Case-Insensitive.

Então por que estou escrevendo este post ? Pra mostar uma forma de se fazer busca Case-Insensitive em um ArrayList.

Busca Case-Insensitive em ArrayList.

Isto é, buscar uma string em uma lista sem considerar o case.

Vamos criar um método estático que recebe um ArrayList, um string para ser buscada e então retorna true se a string existir e false se não existir, considerando a comparação Case-Insensitive:

public static bool ContemValor(string valor, ArrayList lista)

{

ArrayList aux = new ArrayList(lista);

aux.Sort();

return (aux.BinarySearch(valor, StringComparer.InvariantCultureIgnoreCase) >= 0);

}

Outra opção é estender a classe ArrayList e sobrescrever o método Contains, segue a implmentacão:

public class ListaCaseInsensitive : ArrayList

{

public override bool Contains(object item)

{

ArrayList aux = new ArrayList(lista);

aux.Sort();

return (aux.BinarySearch(valor, StringComparer.InvariantCultureIgnoreCase) ;

}

Para a inserção essa operação não faz sentido pois se fossémos verificar se um valor, case-insensitive ou não, existe em uma lista antes de inserí-lo na mesma essa lista passaria a ser um tipo de Conjunto, o qual, diferentemente de uma lista, não possui elementos repetidos.

É isso, como podem ver a implementação é bastante enxuta, porém pode causar dúvidas por não ser uma operação nativa de ArrayList ou qualquer outro tipo de lista em .NET 2.0. Essa foi a melhor forma que encontrei de satisfazer esse requisito, caso conheça alguma outra compartilhe conosco!

Espero ter colaborado, se esse assunto te interessou faça um comentário!

MCTS: .NET Framework 2.0 Windows Applications

2008-05-16T09:04:00.000-07:00

Boas Novas! Após árduos sete meses de estudo consegui alcançar a certificação MCTS: .NET Framework 2.0 Windows Applications. Isso significa ser aprovado nos seguintes exames:

(70-536) TS: Microsoft .NET Framework 2.0 – Application Development Foundation

(70-526) TS: Microsoft .NET Framework 2.0 – Windows-Based Client Development.

Não posso deixar de agradecer o apoio da empresa na qual trabalho: Fibonacci Soluções Ágeis. Sem dúvidas este apoio foi de extrema importância para que eu conseguisse alcançar essa conquista. Valeu Fibo!

É muito bom saber que existe mais um profissional MCTS em Goiânia, e além disso o conhecimento adquirido durante esse período de treinamento (estudei sozinho, mas não deixa de ser um treinamento) é de extrema importância para a qualidade do meu trabalho, tanto no software que desenvolvo quanto para os artigos que escrevo neste blog e também para as futuras consultorias que ministrarei, ás quais estão em estágio de planejamento.

Ainda essa semana será postado a continuação do artigo sobre coleções customizadas.

Até breve.

Coleções Case-Insensitive [Parte 01 - Dicionários]

2008-05-16T07:56:00.000-07:00

Certa vez me deparei com o problema de criar dicionários onde as chaves fossem Case-Insensitive, isto é, dicionários onde a chave "nda" fosse considerada a mesma chave "NdA".

Existem diversos cenários onde este comportamento é desejável. Imagine, por exemplo, um dicionário que contém o mapeamento nomeDoCampo para ObjetoCampo, que é usado para representar todos o campos de um objeto formulário.

Se nas regras de negócio o nome do campo for Case-Sensitive, isto é, o campo nomeado "Campo01" for considerado diferente do campo nomeado "CAMPO01", não existe segredo, basta usar um Hashtable ou um Dictionary genérico que o problema estará sanado.

Se, pelo contrário, as regras definirem que os nomes de campo "campo01" e "CAMPO01" devem se tratar do mesmo objeto, então seu dicionário, o qual irá conter esse mapeamento, precisa de um comportamento diferenciado.

Vamos ver como seria o trabalho de verificar se um dado campo, supondo que no nome do campo seja case-insensitive, está presente em um dicionário normal, juntamente com a operação de adição de um novo campo.

static Hashtable campos = new Hashtable();
static void insiraCampo(string nome, object campo)
{
if (!campoExiste(nome))
campos.Add(nome, campo);
}
static bool campoExiste(string nomeDoCampo)
{
foreach (DictionaryEntry entrada in campos)
{
if (entrada.Key.ToString().ToUpper().Equals(nomeDoCampo.ToUpper()))
return true;
}
return false;
}

Veja o mesmo exemplo onde a variável campos é um dicionário Case-Insensitive

static Hashtable camposInsensitive = CollectionsUtil.CreateCaseInsensitiveHashtable();
static void insiraCampoCaseInsensitive(string nome, object campo)
{
if (!campos.ContainsKey(nome))
campos.Add(nome, campo);
}
/*
O método campoExiste(string nomeDoCampo) não é mais necessário, basta invocar campos.ContainsKey(nomeDoCampo) para obter o resultado.
*/

O ganho não é apenas na menor quantidade de linhas de código e de um melhor aproveitamento da API .NET, uma das principais vantagens é também o desempenho.

Vejam abaixo as diferenças entre os tempos de inserção usando as duas formas:

Quantidade de Itens Inseridos		100	1000	5000	10000
Tempo	Hashtable normal (ms)	156250	650000	196093750	930468750
Tempo	Hashtable Case-Insensitive(ms)	0	0	0	312500

Baixe o código de testes clicando aqui.

Configurações da máquina de Testes:

1.75 GB de Memória RAM
Processador AMD Athlon 64 x2 - Dual Core Processor TK-53

// Forma padrão de se criar um Hashtable Case Insensitive
Hashtable insensitive = CollectionsUtil.CreateCaseInsensitiveHashtable();
/*
Criação de um Hashtable Case Insensitive informando o número máximo de entradas que o objeto suporta.
*/
Hashtable insensitive2 = CollectionsUtil.CreateCaseInsensitiveHashtable(1000);
/*
Criação de um Hashtable Case Insensitive baseado em um Dicionário existente
o dicionário recebido com argumento é não-genérico, mas caso deseje realizar essa operação com um dicionário genérico basta fazer o cast que funcionará corretamente.
*/
IDictionary<object, string> dicionario = new Dictionary<object, string>();
dicionario.Add("chave01", "Qualquer coisa");
dicionario.Add("Chave01", "Outra Coisa");
dicionario.Add("chave02", "Qualquer coisa denovo");
dicionario.Add("Chave02", "Mais uma coisa");
// Dispara um ArgumentException
Hashtable insensitive3 = CollectionsUtil.CreateCaseInsensitiveHashtable(dicionario as IDictionary);

No próximo post irei falar um pouco sobre a manipulação Case-Insensitive de outros tipos de Coleções.

Espero ter contribuído, e fiquem a vontade para comentar e questionar sobre este post!

Abraços