Apensar das coisas não terem muito a ver uma com a outra, comecei a traçar uma linha entre Counter-Strike e Desenvolvimento de Software, uma espécie de “boas práticas” comuns para ambos. Pensei muito antes de escrever esse post, depois desencanei e vi que o máximo que pode acontecer é que essas dicas ajudem vocês a desenvolver melhor ou a jogar melhor, então vamos lá:

Não adianta ser estrela em time que está perdendo: Mesmo com o melhor jogador no seu time, não há garantias de que o mesmo será campeão. É muito mais efetivo ter membros de nível mediano e bem entrosados em um time do que ter várias “estrelas” jogando no estilo cada um por si.

Evite ser herói: Quando damos de cara com vários membros do time adversário, a melhor estratégia é “correr”. Correndo você poderá enfrentar cada adversário separadamente. Alguns desenvolvedores/times trabalham com várias estórias em simultâneo, o que dá uma falsa impressão de produtividade. Quando falamos em requisitos, a melhor estratégia também é dividir para conquistar, ou seja, ao invés de “atacar” várias ao mesmo tempo, podemos atacá-las uma de cada vez (Imagine todo o time atirando em um único membro do time adversário ).

90% não é 100%: É sempre melhor tirar 100% de um adversário do que 70% de dois. Um adversário com 1% de life ainda atira, e com ajuda da Lei de Murphy ele pode levar vários membros do time antes de morrer.  Em uma Sprint temos que nos concentrar em terminar cada estória antes de passar para próxima, assim, ao final da Sprint mesmo que não tenhamos concluído todas as estórias teremos algumas concluídas ao invés de todas em 90% (e nada efetivo para entregar).

Ao final de um round, devemos nos preparar para o próximo: Fases rápidas não habilitam a compra de itens no início do round, porém, ao final podemos ir a pontos específicos do mapa e comprar coletes e granadas. Estar preparado no início de uma Sprint pode fazer tanta diferença quanto lançar uma granada no início do round, mas, afinal de contas o que seria estar preparado? Poderia ser a obtenção de um conhecimento específico que adiantaria todos os requisitos em 50% de todas as estórias por exemplo.

Ser efetivo e econômico traz grandes vantagens: Se você pode acabar com um adversário com uma única bala (Headshot), por que usar 10? Quanto menos balas você gastar menos terá que recarregar durante o round, o que pode salvar sua vida. Ninguém começa no CS conseguindo 100% de Headshots, esse número vai crescendo com o tempo e experiência (pelo menos com os jogadores normais). Na área de desenvolvimento, ninguém nasce extremamente produtivo, porém, é nossa obrigação buscar aumentar a produtividade através de novos conhecimentos e/ou novas ferramentas.

Quem fica parado morre: Preciso argumentar?

Adaptabilidade é crucial: Você pode ter sua arma predileta, mas ela pode não ser a mais efetiva em algumas fases ou em algumas situações. Na área de desenvolvimento temos cada desenvolvedor tem sua ferramenta preferida, pode ser um linguagem, um framework, uma IDE, etc. O ideal no ramo de desenvolvimento é não ficar preso as coisas somente pela predileção, mas sim pela sua efetividade no contexto em que será aplicada.

Poderia enumerar aqui várias outras práticas que ajudam em ambas as partes, mas prefiro deixar vocês pensarem no assunto e quem sabe compartilharem aqui os seus pensamentos.

Para variar, vou jogar um pouquinho.

Abraços!

A idéia era o Dilter Porto (@dilterporto) apresentar o NHibernate e eu apresentar o EF4. Conversamos muito nas semanas que antecederam o evento e decidimos não falar puramente das ferramentas. Tomei a liberdade de falar não só de EF4, mas sim como eu tenho utilizado o EF4, sendo assim, falei sobre Arquitetura de software, TDD, Domain-Driven Design, DI, Repository e finalmente EF4. O Dilter abordou desde a teoria dos ORMs até sua experiência na utilização do NHibernate. Os feedbacks que tivemos é que as palestras se encaixaram perfeitamente. Gostei muito da seleção de informações que foram apresentadas no evento.

Após as duas palestras tivemos uma mesa redonda mediada pelo Rafael Hrasko (@hrosko) com perguntas e comparações sobre os dois ORMs. Procurei deixar bem claro que não curto vestir camisas de tecnologias, e sim tentar aplicá-las da melhor forma para solucionar os meus problemas. Tivemos perguntas bem interessantes sobre Performance, facilidades, maturidade, etc. Acredito que esse tenho sido um dos melhores eventos que participei ultimamente.

Vídeo da palestra

Apresentação

Fotos do evento

Abraços!

Acredito que a segunda versão do evento ficou ainda melhor que a primeira. Mudamos algumas abordagens, inserimos alguns assuntos importantes e procuramos trabalhar de uma forma dinâmica e interativa com os participantes. Vou relatar agora um pouco do que aconteceu no evento:

.NET 4.0 e Visual Studio 2010

Nesse evento procuramos apresentar todos os recursos do Framework .NET desde a sua primeira versão lançada em 2003. O objetivo principal dessa parte do evento foi mostrar a maturidade da plataforma e como a mesma vem sendo melhorada de forma contínua e incremental (desde sua versão 2.0).

Como a idéia era fazer uma espécie de túnel do tempo das tecnologias Microsoft, procuramos abordar desde as características mais básicas da versão 2.0 do framework até as novidades mais quentes da versão 4.0 (versão mais atual).

Depois do apanhado histórico sobre o framework, fizemos algumas demonstrações das ferramentas de arquitetura do Visual Studio 2010, tais como: Gráfico de Dependências e Diagrama de camadas.

É impressionante perceber o mundo de ferramentas que temos à disposição no Framework .NET, e essa foi a idéia dessa apresentação, mostrar o poder que temos nas mãos utilizando essa plataforma.

Scrum e Agilidade

O André Pires apresentou o Scrum de uma forma muito interativa e dinâmica. Visitamos os conceitos do Scrum, seus papéis, artefatos, regras, cerimônias e recomendações. Acredito que todos os participantes tiveram uma visão bem clara do framework.

Gosto muito de discutir sobre Agile e Scrum. Apesar de não ser o palestrante desse tema, foi muito rico só ouvir os questionamentos feitos pelos gerentes de projetos que estavam presentes. O André apresentou com maestria o tema discorrendo sobre as grandes dúvidas e questionamentos dos gerentes de projeto tradicionais ao mundo ágil.

A apresentação terminou com uma dinâmica que exemplificava a utilização do Scrum. Os participantes tinham que atingir um objetivo específico em um tempo limite. O bacana é que o PO (André) passava pelas equipes gerando pequenos impedimentos e interferindo nos trabalhos, o que gerou fortes reações pela parte de alguns ScrumMasters.

Volto a destacar que, apesar de entender do tema, nada paga a troca de experiências que temos com os participantes do evento.

Técnicas de engenharia de software e TDD

Diferente da versão anterior desse evento, abordamos a importância da orientação a objetos e das técnicas de engenharia em projetos de software que usem processos interativos e incrementais na produção.

Fizemos algumas reflexões sobre qualidade de software e discutimos como é importante utilizar técnicas para construir o projeto que façam com que o custo de evolução não seja discrepante do custo de produção. Afinal de contas, em processos iterativos estamos sempre evoluindo o projeto.

Aprofundamos alguns conceitos que o André havia citado na palestra sobre Scrum. Falamos sobre POO, Design Patterns, CI, ORMs (Entity Framework e NHibernate), Programação em par, Testes unitários, DDD e TDD. Foi muito legal apresentar uma visão geral sobre esses assuntos que estão em alta nas listas de discussão mais ativas.

Finalmente, apresentamos o TDD de uma forma resumida como primeira prática a ser adotada dentre todas as práticas que havíamos discutido nessa etapa do evento.

O objetivo principal dessa parte do evento foi mostrar aos participantes que investir nas disciplinas apresentadas é um investimento tão importante quanto o investimento feito no aprendizado das tecnologias (ou mais).

Fotos do evento

Estamos preparando muitas novidades para o próximo evento, fiquem ligados!

Abraços!

Batman - DC Universe Online

Olá Pessoal! No meu primeiro post sobre Design By Contract recebi questionamentos interessantes sobre os prós e contras dessa abordagem comparando-a com a forma tradicional de validações com if…throw, logo, o objetivo deste post será evidenciar as diferenças entre essas duas abordagens.

No último post lancei um desafio ao meu amigo Gustavo Badke (@guripunk) após ele ter escrito o seguinte comentário: “Pra min isso é firula, não vejo diferença nenhum do if(…) throw new Exception…“. Alguns códigos que vou apresentar aqui foram escritos por ele, então, considerem-no como uma participação especial nesse post . Vamos lá:

Pré-condições

Tradicionalmente, quando precisamos verificar se os parâmetros de um método qualquer estão válidos para utilização, escrevemos algo semelhante ao código abaixo:

1
2
3
4
5
6
7
8
9
10
11

public Cor(int pVermelho, int pVerde, int pAzul)
{
    if (pVermelho < 0 || pVermelho > 255)
        throw new ArgumentOutOfRangeException("O argumento 'pVermelho' deve ser entre 0 e 255");
    if (pVerde < 0 || pVerde > 255)
        throw new ArgumentOutOfRangeException("O argumento 'pVerde' deve ser entre 0 e 255");
    if (pAzul < 0 || pAzul > 255)
        throw new ArgumentOutOfRangeException("O argumento 'pAzul' deve ser entre 0 e 255");
 
    // Implementação...
}

A abordagem acima resolve o nosso requisito de validação dos parâmetros, porém, o código utilizado para isso é extremamente “carregado” para a implementação de um requisito simples. Utilizando DbC a implementação ficaria da seguinte forma:

1
2
3
4
5
6
7
8

public Cor(int pVermelho, int pVerde, int pAzul)
{
    Contract.Requires<ArgumentOutOfRangeException>(pVermelho >= 0 && pVermelho <= 255);
    Contract.Requires<ArgumentOutOfRangeException>(pVerde >= 0 && pVerde <= 255);
    Contract.Requires<ArgumentOutOfRangeException>(pAzul >= 0 && pAzul <= 255);
 
    // Implementação...
}

A abordagem acima não só resolve o nosso requisito de validação dos parâmetros, como também deixa o código mais legível e você ainda conta com a validação dos contratos em tempo de compilacão. O método Requires ainda possibilita a configuração de uma mensagem personalizada caso seja necessário.

Também poderíamos usar AOP para resolver nosso problema, contudo, seria utilizar um recurso muito poderoso e complexo para uma necessidade muito simples. Se você não vai usar AOP para nenhuma outra necessidade do seu projeto, não recomendo utilizar nessa situação.

Não devemos avaliar o poder do DbC analisando somente suas pré-condicões. Precisamos avaliar se todos os aspectos dessa abordagem serão realmente úteis no nosso projeto, isso inclui também as pós-condições e invariantes.

Pós-condições

É comum, após a execução de um método, realizar a verificação de estado da classe nos membros que foram afetados pelo mesmo. Nessa situação, usando a abordagem tradicional, faríamos uma verificação qualquer no final do corpo do método. Algo como mostra o código abaixo:

1
2
3
4
5
6
7

public void AdicionarVermelho(int pValor)
{
    this.Vermelho += pValor;
 
    if (this.Vermelho > 255)
        throw new Exception("A propriedade Vermelho não deve ser maior que 255");
}

Um dos principais problemas nessa abordagem é a falta de legibilidade no método. Veja a solução usando DbC:

1
2
3
4
5
6

public void AdicionarVermelho(int pValor)
{
    Contract.Ensures(this.Vermelho <= 255);
 
    this.Vermelho += pValor;
}

Quando trabalhamos com contratos, sempre inserimos os mesmos no topo dos métodos, o que facilita muito a leitura dos códigos. Mesmo com exemplos simples como esses, podemos perceber que a curva de aprendizagem é muito baixa.

Invariantes

Como você garantiria que um objeto estará válido sempre independente de quais e quantos métodos forem executados? Provavelmente, você precisará construir algum método de validação e chamá-lo ao final de cada método público de sua classe. Nesse ponto, percebemos uma grande diferença entre as abordagens, pois usando DbC, só precisaríamos construir o método Invariant com as validações necessárias e pronto, vejam o exemplo:

1
2
3
4
5

[ContractInvariantMethod]
private void Invariant()
{
    Contract.Invariant(this.Vermelho <= 255);
}

Em resumo, como disse anteriormente, é necessário analisar todos os recursos da abordagem e não somente um. Apensar das pré-condições serem facilmente substituídas por if…throw, isso não acontece da mesma forma com as invariantes.

DbC não é para todos os projetos, DbC não é regra, DbC não é melhor ou pior que ninguém. Use em seus projetos quando precisar de todos os recursos que a abordagem dispõe, e mesmo assim não deixe de analisar alternativas como AOP.

Abraços Pessoal!

Links contidos na apresentação

CSS Zen Garden
http://www.csszengarden.com/

Html
http://www.w3schools.com/html/
http://www.w3schools.com/tags/

W3C
http://pt.wikipedia.org/wiki/W3C
http://validator.w3.org/

Java Script
http://nagueva.com/o-que-e-javascript-nao-obstrutivo/
http://dev.opera.com/articles/view/the-seven-rules-of-unobtrusive-javascrip/
http://gujs.com.br/blog/2007/04/compactacao-javascript/
http://www.prototypejs.org/
http://www.scripteka.com/

CSS e Tableless
http://www.tableless.com.br/
http://www.oficinadanet.com.br/area/31/tableless/
http://maujor.com/
http://maujor.com/tutorial/hacks-css.php

Performance
http://www.meiocodigo.com/category/css/
http://www.meiocodigo.com/exemplos/bg-position/

Abraços!

Nos projetos em que usei AOP, trabalhei com o framework PostSharp, mas no podcast também abordamos Aspect.NET e AspectJ.

Vale muito a pena pesquisar sobre o tema.

Podcast

Post no DNA

http://podcast.dotnetarchitects.net/2010/05/podcast-13programacao-orientada-a-aspecto/

Dicas gerais sobre TDD

Sempre inicie com uma lista de testes : No TDD, não saímos codificando. Antes de iniciar a construção de qualquer coisa, elabore uma lista de testes inicial. Caso seja necessário, você poderá incluir mais itens na sua lista de testes mesmo depois de já ter iniciado a codificação;

Sempre inicie pelo teste mais simples : Após elaborar sua lista de testes, inicie a codificação pelo teste mais simples da sua lista. Desenvolvendo dessa forma, você não só ganha ritmo, mas também vai aprendendo de pouco a pouco sobre o problema que está resolvendo.

Comece a construção do seu código pela construção do seu teste : Desenvolvendo o teste primeiro (como preza o TDD) temos a oportunidade de tomar decisões de design das nossas classes antes mesmo de construí-las. Iniciar a construção do código pelo teste possibilita que você veja o seu código pela perspectiva de quem o utilizará, ou seja, você terá um feedback de utilização antes mesmo de codificar sua classe.

Comece o teste pela assertiva : Iniciar o teste pela assertiva é definir o objetivo do teste. Escrever a assertiva é definir onde você quer chegar no teste, qual objetivo quer alcançar, se isso não estiver bem definido não adianta escrever o teste.

Simule até construir realmente : Sempre que possível, construa implementações falsas. Deixe para construir as implementações reais só quando for realmente necessário.

Busque o verde o mais rápido possível : Quando o teste estiver vermelho, procure fazê-lo passar o mais rápido possível, mesmo que a implementação feita não seja a mais agradável de ver. Quando o teste estiver verde, substitua a implementação feita por uma implementação mais elegante, afinal, a fase de refatoração serve para isso.

Construa somente o necessário para o teste passar : Não construa nada além do que o seus testes pedirem. Se desejar realizar alguma codificação, escreve primeiro um teste e depois o código. TDD também exige muita disciplina.

Passos de bebê : Procure sempre dar passos pequenos durante a construção dos seus testes, evite assumir um teste muito difícil ou grande logo de cara, deixe sempre os testes mais complicados para o final.

Links

Faça download do projeto construído: ConversaoNumerosRomanos

Veja outros links sobre TDD no delicious: delicious.com/denisferrari/tdd

Abraços!

O conceito DbC é usado para garantir o estado de seus objetos em tempo de execução. Basicamente, quando construímos nossa classe usando o conceito DbC, definimos acordos formais (o que chamamos de contratos) com quem a utiliza. Esses contratos visam garantir regras de utilização e estado, regras essas que são expressas através de pré-condições, pós-condições e invariantes.

Vamos explorar algumas situações do nosso dia-a-dia para fortalecer o conceito e aprender a utizar a classe Contract que se encontra no namespace System.Diagnostics.Contracts:

Como podem ver no código abaixo, estou criando uma classe chamada Cor que receberá no construtor uma string contendo o código hexadecimal. No teste, desejo garantir que caso a classe Cor seja instanciada com um parâmetro nulo, uma exceção do tipo ArgumentNullException seja lançada.

1
2
3
4
5
6

[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void Deve_rejeitar_parametros_nulos()
{
    var cor = new Cor(null);
}

Para fazer o nosso teste passar, poderíamos verificar se o parâmetro é nulo usando if e lançar a exceção, porém, quando pensamos em contratos, o que fazemos é criar uma pré-condição de utilização da nossa classe. Para construir pré-condições, utilizamos o método Requires da classe Contract informando qual tipo de exceção será lançada caso o contrato for quebrado. Vejam o código abaixo:

1
2
3
4
5
6
7
8
9

public class Cor
{
    public Cor(string pCodigoHexadecimal)
    {
        Contract.Requires<ArgumentNullException>(pCodigoHexadecimal != null);
 
        // Código que converte o hexadecimal...
    }
}

Como podem ver, o código fica bem mais limpo e expressivo. Sem falar que caso você tenha o plugin do Visual Studio instalado terá essas verificações de constrato em tempo de design, isso mesmo, enquanto você cria suas classes seu código será analisado para verificar possíveis quebras de contrato. Vejam a imagem abaixo:

Vamos para outra situação: Agora nossa classe Cor possui um construtor que recebe as taxas de vermelho, verde e azul. Construímos um método para adicionar tonalidades de vermelho na cor, porém, a taxa máxima permitida de vermelho é de 255.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

[TestMethod]
public void Deve_garantir_taxa_de_vermelho_menor_ou_igual_255()
{
    var vermelho = 200;
    var verde = 200;
    var azul = 200;
    var cor = new Cor(vermelho, verde, azul);
 
    try
    {
        cor.AdicionarVermelho(56);
    }
    catch
    {
        // O método deve lançar a exceção pois 200 + 56 ultrapassa o limite de 255.
        Assert.AreEqual(vermelho + 56, cor.Vermelho);
    }
}

Para garantir o limite da taxa de vermelho no nosso objeto, precisamos que o nosso método seja executado para então verificar o estado. Em DbC podemos criar uma pós-condição para avaliar o estado do nosso objeto ao final da execução do nosso método/propriedade. No exemplo abaixo usamos o método Ensures para criar a pós-condição que verifica a taxa de vermelho do nosso objeto após a execução do nosso método. Os contratos sempre são definidos no início dos métodos/propriedades.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class Cor
{
    public int Vermelho { get; private set; }
 
    public Cor(int pVermelho, int pVerde, int pAzul)
    {
        this.Vermelho = pVermelho;
        // Configurar as outras propriedades...
    }
 
    public void AdicionarVermelho(int pValor)
    {
        // Aqui estamos garantindo que ao final da execução desse método, a propriedade Vermelho deverá respeitar o limite de 255;
        Contract.Ensures(this.Vermelho <= 255);
 
        this.Vermelho += pValor;
    }
}

As pós-condições são tão simples de serem escritas quanto as pré-condições.

Outra forma de garantir o nosso limite de 255 é criar um contrato invariante, ou seja, uma regra que será mantida sempre, independente de quais método forem executados no objeto. Para criamos o contrato invariante no .net usamos o método Invariant da classe Contract. Métodos invariantes são verificados sempre após a execução de qualquer método público da sua classe, eles só devem ter declarações de contratos e não podem retornar valores.

1
2
3
4
5

[ContractInvariantMethod]
private void Invariant()
{
    Contract.Invariant(this.Vermelho <= 255);
}

Como vimos, DbC é uma obordagem muito interessante e pode nos auxiliar muito no dia-a-dia. O objeto desse post não é apresentar bons padrões para design de testes ou grandes soluções no trabalho com cores, os exemplos aqui mostrados visam apenas apresentar alguns recursos da classe Contract. Façam os devidos testes e contem o que acharam do recurso e dessa abordagem.

Separei alguns links interessantes sobre o assunto no delicious, veja no link: delicious.com/denisferrari/DbC.

Fico no aguardo do feedback de vocês.

Abraços!

Engraçado como as coisas acontecem, olhando as fotos da palestra vejo que um dos coordenadores do MSDev-ES e atual membro do time de desenvolvimento da Mindworks estava lá, o Rafael Hrasko. A foto também mostra o ponto onde iniciei algumas boas amizades, afinal, ainda sou formando na Faesa.

A idéia da palestra surgiu a partir de algumas conversas com o Prof. Lourival, que sempre foca nas suas aulas em dicas sobre a carreira e no desenvolvimento profissional dos alunos. Fiquei muito feliz com a confiança depositada em mim pelo Prof. Lourival, afinal de contas, não sou tão mais velho do que os alunos daquela turma, só iniciei na área mais cedo. Depois dessa palestra, decidi escrever algumas idéias sobre Mercado e Carreira, e ingressei no time de colaboradores do Portal Minha Carreira.

Decidi gravar a palestra no formato de screencast e disponibilizá-la aqui no entuito de ajudar quem estiver começando nessa área da qual me orgulho tanto trabalhar. Espero que gostem. Aguardo o Feedback de vocês.

Screencast

Fotos

Apresentação

Falar para pessoas que estão iniciando na área de desenvolvimento de software é uma extrema responsabilidade, por isso, ao invés de falar somente sobre TDD procurei mostrar alguns problemas da área e boas práticas através do case do meu primeiro projeto de software relevante (tinha 17 ou 18). Esse projeto foi realmente traumático, porém, definiu muitos dos meus paradigmas atuais sobre a carreira e o desenvolvimento de software em geral.

Troquei muitas informações com os profissionais locais após a minha palestra, fizemos tanto networking que acabei nem assistindo a segunda palestra do evento. Outro ponto relevante é que muitas pessoas que estavam lá tinham comparecido ao Maré-VIX, evento que organizei no CET-Faesa poucos dias antes.

Fotos

Slides da apresentação

Espero que os presentes tenham gostado do evento assim como eu gostei. Agradeço ao MIC e a UNES pela oportunidade e pela confiança.

Abraços!

Esse podcast ficou muito legal, rolaram discussões muito bacanas sobre o assunto, sem falar que os comentários nos bastidores da gravacão são muito engraçados.

Espero que gostem dos tópicos apresentados no podcast.

Podcast

Post no DNA

http://podcast.dotnetarchitects.net/2010/03/podcast-11-modelo-anemico/

Foi uma imensa responsabilidade apresentar novas ferramentas e principalmente novas idéias em desenvolvimento de software para representantes das empresas do mercado capixaba e para os desenvolvedores presentes. Vejam como foi cada parte do evento:

Novidades do Visual Studio 2010

Abri o evento apresentando as novidades do Visual Studio 2010, e não tinha como não ficar empolgado com tanta coisa boa! Queria mostrar exemplos de tudo, mas não havia tempo, e ainda assim atrasei “um pouco” a minha palestra para apresentar todos os recursos que tinha preparado. Alguns tópicos abordados:

• IntelliTrace
• Gráfico de dependências
• Diagrama de camadas
• Ferramentas para Deploy
• Novidades do C# 4.0
• Novidades do ASP.NET 4.0
• Code Analysis
• Performance Analysis
• Biblioteca para Paralelismo
• Novidades no desenvolvimento para SharePoint

Ao final da apresentação, quem já gostava do Visual Studio passou a gostar mais, e quem não conhecia viu o poder dessa IDE.

Scrum e Desenvolvimento Ágil

O André Pires apresentou muito bem a metodologia ágil e seus princípios.  Como de costume, a palestra dele foi muito interativa e divertida. Discutimos muito com os representantes do mercado e do governo o cenário atual dos nossos projetos de software e por que precisamos adotar novas estratégias se quisermos melhorar nossas estatísticas de sucesso.

Essa palestra foi praticamente em dupla, pois o André sempre solicitava relatos de experiências e complementações da minha parte. Aproveitei para explicar a importância do trabalho iterativo e por que projetos de software são tão difíceis de serem estimados.

Gosto muito do assunto e das discussões que rolam, mas a impressão que tive é que todos os presentes concordaram que a forma de trabalho que estávamos apresentando possuía práticas que facilitariam o desenvolvimento como um todo.

TDD e Ferramentas de garantia da qualidade no Visual Studio 2010

Tenho falado muito sobre TDD aqui em Vitória. Por questões de tempo, procurei não apresentar todas as dicas que geralmente dou e mostrar um exemplo prático de aplicação do TDD, uma espécie de TDD para iniciantes.

A segunda parte da palestra foi dedicada as ferramentas de Teste do Visual Studio. Gosto muito dessas ferramentas, a Microsoft acertou mais uma vez, apesar de ainda acreditar que eles podem melhorar a biblioteca Microsoft.VisualStudio.TestTools.UnitTesting para dar mais poder e semântica aos testes unitários.

TFS

Só o TFS daria um evento inteiro. O André apresentou a utilização do template Scrum e mais uma série de recursos do TFS, os presentes realmente ficaram impressionados com o nível de integração e as facilidades que os recursos apresentados geram para a equipe.

Fotos do evento

Apesar do trabalho que dá, não vejo a hora do próximo evento.

Agradeço a todos os presentes e a Mindworks pela oportunidade.

Abraços!

Após vários debates sobre o tema, decidi fazer um post sobre Previsibilidade em desenvolvimento de software. Decidi abordar o tema em uma apresentação ao invés de escrever, pois acredito que assim consegui expressar melhor as características que fazem com que seja tão difícil na nossa área estimar o tempo de desenvolvimento dos projetos.

Veja mais sobre previbilidade em desenvolvimento de software na tag “Previsibilidade” no delicious: delicious.com/denisferrari/Previsibilidade

Fico no aguardo dos feedbacks!

Abraços!

O exemplo que vou mostrar aqui é básico, pois esse framework tem vários recursos legais que serão abordados em outros posts. Vou mostrar um pouco da teoria sobre DI e como utilizar o Ninject para aplicar esse pattern.

Quando utilizamos um componente qualquer, estamos acoplando o mesmo a nossa solução. Componentes atendem a necessidades específicas, por exemplo: Enviar e-mail, gerar pdf, compactar arquivos, etc. O que buscamos com o pattern DI é usar esses componentes sem acoplá-los diretamente a nossa solução, e basicamente conseguimos isso através de interfaces.

Vamos começar declarando uma interface IContrato. Esse interface representa uma necessidade qualquer da sua solução, e todos os seus algoritmos devem considerar apenas os membros desse interface.

1

public interface IContrato { }

A interface que criamos precisa de uma implementação concreta, pois como vimos, ela só representa nossas necessidades. O próximo passo é criar a classe Fornecedor que irá implementar a interface IContrato. Nosso desafio nesse exemplo é usar a classe Fornecedor no nosso código sem criar uma referência direta, ou seja, não poderemos usar o new para obter uma instância da classe Fornecedor.

1

public class Fornecedor : IContrato { }

A grande solução aqui é delegar a responsabilidade de intanciar os nossos componentes para um terceiro elemento, que nesse caso é o Ninject. Precisamos dizer ao Ninject qual classe queremos que resolva a interface IContrato, para isso, precisamos criar um Módulo e nele configurar os Binds.

1
2
3
4
5
6
7
8

public class Modulo : NinjectModule
{
    public override void Load()
    {
        // Configuramos para que a interface IContrato seja direcionada para a classe Fornecedor;
        Bind<IContrato>().To<Fornecedor>();
    }
}

Agora vamos a utilização do Ninject. Criei um método de teste para exemplificar como configuramos e usamos a classe Kernel, que é a classe responsável por retornar as instâncias dos componentes que precisamos a partir da interface.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[TestMethod]
public void Deve_obter_fornecedor_pelo_contrato()
{
    // Instancia o módulo;
    var modulo = new Modulo();
 
    // O Kernel é a classe responsável por fornecer as instâncias necessárias para o código;
    IKernel kernel = new StandardKernel(modulo);
 
    // O método Get devolve a instância da classe mapeada para a interface;
    IContrato meuContrato = kernel.Get<IContrato>();
 
    Assert.IsNotNull(meuContrato);
    Assert.IsInstanceOfType(meuContrato, typeof(Fornecedor));
}

Como vimos anteriormente, podemos solicitar ao Kernel uma instância de classe manualmente, porém, o Ninject possibilita configurar as dependências de uma classe a partir do atributo [Inject]. Vamos declarar uma classe chamada Servico com uma propriedade do tipo IContrato.

1
2
3
4
5

public class Servico
{
    [Inject]
    public IContrato Fornecedor { get; set; }
}

Vamos aos testes. Podemos perceber no teste abaixo que o método Inject da classe Kernel resolve todas as dependências da instância da classe Servico.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[TestMethod]
public void Deve_resolver_dependencias_manualmente()
{
    IKernel kernel = new StandardKernel(new Modulo());
 
    // A instância normal não tem as dependências resolvidas;
    var servico = new Servico();
 
    Assert.IsNull(servico.Fornecedor);
 
    // O método Inject resolve as dependências da instância usando como marcador o atributo [Inject];
    kernel.Inject(servico);
 
    Assert.IsNotNull(servico.Fornecedor);
    Assert.IsInstanceOfType(servico.Fornecedor, typeof(Fornecedor));
}

Nesse teste, percebemos que se solicitarmos uma instância da classe Servico diretamente ao kernel do Ninject, o mesmo já resolverá as dependências internas da classe.

1
2
3
4
5
6
7
8
9
10
11

[TestMethod]
public void Deve_resolver_dependencias_automaticamente()
{
    IKernel kernel = new StandardKernel(new Modulo());
 
    // Quando solicitamos uma instância de classe, a mesma é devolvida com as dependências resolvidas.
    var servico = kernel.Get<Servico>();
 
    Assert.IsNotNull(servico.Fornecedor);
    Assert.IsInstanceOfType(servico.Fornecedor, typeof(Fornecedor));
}

Como vimos, o grande truque aqui é delegar a responsabilidade de criação das instâncias para o kernel do Ninject. Como não utilizamos em nenhum momento o new para instanciar a classe Fornecedor, podemos substituí-la só alterando o Bind na classe Módulo.

Posteriormente vou postar outros artigos sobre Ninject focando em características mais específicas do framework.

Para mais referências, visite a tag Ninject no delicious: delicious.com/denisferrari/Ninject

Você pode baixar o projeto pelo Google Docs: Faça o Download

Abraços!

Atendendo um pedido interno da Mindworks, fiz um projeto muito simples que tinha um requisito principal: Copiar pastas de várias origens para um mesmo destino. Fiz o projeto rapidamente, usei TDD para construção dos processos e Serialização e Desserialização para obtenção das origens e destinos. O problema é que em uma linha de código eu copiava a pasta de um lugar para o outro, e só nesse momento lembrei que o .NET não copia o conteúdo das pastas automaticamente. Apesar de não ser tão trabalhoso a construção desse código, eu não tinha muito tempo restante, então, decidi procurar por uma biblioteca pronta que o fizesse. Foi meu primeiro contato com o xDirectory.

Como produzi o código respeitando a separação de responsabilidades e a coesão dos componentes, só precisei alterar uma linha de código para usar o xDiretory, sendo assim, todo o processo que construí manualmente estava coberto por testes unitários, e como meu código não estava usando o componente diretamente realizar a alteração do mesmo foi muito simples.

O xDirectory pode ser encontrado no link abaixo, vale a pena conferir:
http://www.codeproject.com/KB/files/xdirectorycopy.aspx

Abraços!

Dojo

É com grande orgulho que tenho o prazer de anunciar o Primeiro Coding Dojo realizado pelo grupo MsDev-ES.

Como desenvolvedores, sempre estamos estudando assuntos diversos para melhorar nossas habilidades profissionais, porém, com o passar do tempo, acabamos viciados em algumas soluções ou práticas e, sem perceber, paramos de evoluir. O Coding Dojo é uma reunião que visa melhorar sua habilidades de programação, fazer com que você conheça gente nova e de quebra você ainda se diverte!

O Coding Dojo faz você pensar fora da caixa! Você irá programar em par utilizando TDD para solucionar problemas que não aparecem no nosso dia-a-dia e, de quebra, aprende truques novos com pessoas que você nunca teve a oportunidade de trabalhar!

Você não possui experiência? Não importa! O objetivo do Coding Dojo é aprendizado, ou seja, o lugar certo para qualquer pessoa que deseja aprender, independente da experiência profissional!

O encontro será na faculdade Faesa às 10:00 no sábado, 24 de abril. A reunião será na Sala 10 do Bloco IV.

Não perca tempo! Inscreva-se e garanta sua vaga no Primeiro Coding Dojo do MsDev-ES!
Preencha o formulário de inscrição!

Quer saber mais sobre Coding Dojo? Veja o post do Uilton Campos:
http://uiltoncampos.wordpress.com/2010/04/19/coding-dojo/

Não perca tempo! As vagas são limitadas! Realize já sua inscrição e garanta sua vaga!

Vejo vocês lá!

Abraços!

O Concurso

No início do semestre passado eu iniciava a disciplina de empreendedorismo na Faesa. Passei boa parte do curso de sistemas de informação esperando por essa disciplina e as reflexões que ela causaria, porém, não imaginei que ela ofereceria a grande oportunidade de participar do Uniempreendedor, o concurso que é organizado anualmente pela Tecvitória para avaliar o potencial empreendedor do estudante.

O objetivo do concurso é avaliar dentre os projetos submetidos, qual tem a maior chance de gerar bons resultados como produto ou serviço. A faculdade seleciona os melhores projetos e envia para Tecvitória que, por sua vez, realiza uma série de avaliações até que os projetos restantes sejam apresentados para uma banca avaliadora que definirá o resultado do concurso.

A Oportunidade

Em paralelo à disciplina de empreendedorismo, o Sr. Uilton Campos e Eu estávamos preparando nosso TCC. Quem já passou por essa etapa da vida sabe o esforço necessário para conclusão desse trabalho e, como nosso projeto possui uma complexidade considerável, tínhamos mais trabalho que o normal.

Quando o professor divulgou o concurso em sala de aula, não pensei duas vezes, marquei uma reunião e apresentei o projeto com todos os argumentos que eu tinha na manga. Ao final, não existiam razões para que o mesmo não concorresse.

O poder de persuasão foi exaustivamente testado pois, além de convencer o professor que projeto era viável sem possuir um protótipo, também era necessário convencer Uilton, devido ao fato de já estarmos totalmente sem tempo, graças ao TCC.

Uma das principais características do empreendedor é acreditar na sua idéia e conseguir fazer com que as pessoas que estão ao seu redor também acreditem ao ponto de quererem ajudá-lo. Na minha opinião, essa característica definiu essa etapa.

A Faesa selecionou dois projetos para o concurso: O Velloz (nosso projeto) e um Jogo on-line desenvolvido por Rafael Hrasko.

O Desenvolvimento do projeto

A proposta que foi submetida inicialmente era muito simples. Era bascimente uma visão geral do projeto.

Quando chegamos à segunda fase do concurso, fomos premiados com um curso para análise de viabilidade técnica e financeira de projetos. O curso foi ministrado por Douglas Chamon, que, atendendo às minhas preces, é formado em economia e não em marketing.

O curso foi muito produtivo. Ganhamos argumentos para provar a viabilidade dos projetos de uma forma que não conhecíamos. Foi também nessa fase que conhecemos melhor os projetos concorrentes.

Todo dia após o curso tínhamos uma missão: Melhorar o nosso plano de negócios. Era muito trabalho para pouco tempo pois, logo ao final do curso, já tínhamos que entregar o documento. Uilton e Eu passamos o final de semana na Qualidata (empresa que ele trabalha) confeccionando o documento. Eu não agüentava mais olhar para ele e vice-versa. Foi extremamente cansativo.

O documento tinha que apresentar os detalhes da execução do projeto. Só as equipes que persistiram chegaram ao final dessa fase, pois algumas pessoas perceberam durante o curso que seus projetos não eram viáveis. Foi necessária muita força de vontade para concluir essa etapa.

O pior entrave dessa fase foi separar o que era plano de negócios do que era TCC. Como estávamos desenvolvendo os dois ao mesmo tempo, em alguns momentos nossas mentes não faziam essa distinção.

A experiência de escrita foi muito rica e muito cansativa. Basicamente tínhamos sempre que dizer indiretamente as coisas, de forma responsável e com as respectivas fontes. O documento ficou muito bom (avaliação pessoal) e até hoje, o tenho como referência para elaboração de documentos semelhantes.

A Defesa do projeto

Depois de ouvir todo tipo de rumores sobre a banca de avaliação, fiquei extremamente preocupado com os questionamentos que seriam feitos. O que aumentou minha insegurança foi que na mesma época eu havia realizado uma palestra, na qual não obtive um bom desempenho. Sendo assim, fora a pressão da avaliação, eu estava de moral baixa.

Devido à importância da defesa do projeto, passei o final de semana ensaiando cada parte da apresentação. Sempre me preparei para dar aulas, palestras ou dissertar sobre qualquer assunto em público, mas como estava de consciência pesada devido à minha última performance, não podia errar duas vezes consecutivamente. Até hoje me pergunto se o resultado do concurso seria diferente se eu não tivesse me preparado tanto para a defesa do projeto.

Quando chegamos para apresentação, outra equipe estava apresentando e por sinal sendo muito criticada (o que não quer dizer nada). Entramos, apresentamos o projeto e ao final da apresentação, ocorreu um silêncio na sala. Não sabíamos se o silêncio era bom ou ruim, mas foram alguns segundos de tensão.

A banca elogiou muito a apresentação e o projeto, mas o negócio que estávamos propondo era consultoria, e esse não era o melhor modelo de negócio para o concurso, pois não era tão escalável quanto os outros modelos de negócio. Saí de lá com a sensação de missão cumprida e com minha moral de volta, mas não esqueço a lição da preparação e ensaio, sempre.

O Resultado

Duas semanas após a apresentação o resultado foi divulgado: Ficamos em terceiro lugar. O projeto que ganhou foi o que estava sendo criticado pela banca quando chegamos para a apresentação.

Não gostei de ter ficado em terceiro lugar, mas entendi o motivo. Os outros projetos eram realmente bons e conseguiam ser escalados mais facilmente. Isso definiu o resultado do concurso.

O Prêmio

Fizemos uma viagem à São Paulo, onde finalmente pude conhecer melhor a cidade. O Sr. Vinícius, da Tecvitória fez um tour muito bacana com a gente. Visitamos alguns eventos que estavam ocorrendo e ainda conhecemos a Endeavor, que particularmente, foi a parte da viagem que eu mais gostei.

Como ninguém é de ferro, aproveitamos para conhecer os principais bairros e bares da cidade. Por obra do destino, em pleno Saint Patrick’s Day eu estava em São Paulo e, como devoto fiel, fui celebrar no Asterix (sozinho, pois o pessoal não aguentou e foi dormir cedo).

A experiência do concurso foi muito rica, mas estar em São Paulo como turista tendo a oportunidade de trocar idéias com um empreendedor como o Vinícius da Tecvitória realmente foi muito benéfico.

Conclusão

O Uniempreendedor foi uma experiência única. Daquelas em que a viajem vale mais do que o destino final.

Apesar das noites perdidas, do trabalho e de todo o stress que passamos, eu participaria novamente.

Fica a dica para os empreendedores de plantão. Essa experiência e o conhecimento obtido vão me acompanhar por toda a vida.

Reunião

Há algum tempo houve uma discussão no Grupo .Net Architects sobre a definição de qualidade de software e quais são as formas de alcançá-la. A discussão foi muito produtiva e apresentou idéias e conceitos que todo profissional de desenvolvimento deveria conhecer, segue o link da discussão:

Link da thread no grupo

Algum tempo depois surgiu a idéia de gravar um podcast sobre o tema onde tivemos a oportunidade de participar juntamente com Alexandre Valente e Giovanni Bassi, o resultado final agradou muito:

Link do podcast Qualidade de Software

Aguardo Feedbacks.

Abraços!

Doctor Who

Muitos profissionais da nossa área têm dificuldades em definir qualidade de software devido à quantidade de aspectos que precisam ser considerados para avaliar se um software possui ou não qualidade. Apesar do processo de avaliação da qualidade ser amplo e complexo, a definição de qualidade de software é simples de ser compreendida.

Para avaliar a qualidade de um computador, avaliamos separadamente a qualidade de seus componentes, como vídeo, som, capacidade de processamento e quantidade de memória. A qualidade do computador pode ser considerada uma média das avaliações individuais de seus componentes. No software, a mesma idéia pode ser aplicada, porém, ao invés de olharmos para os componentes que o formam devemos olhar para como ele atende aos seus stakeholders: o cliente que paga pelo software, o usuário que trabalha diretamente com o software no seu dia-a-dia e o fornecedor que constrói ou mantém o software.

Um software que atende ao cliente é aquele que atende ao objetivo para o qual ele foi construído (atender ao objetivo é mais importante do que respeitar o escopo inicial). Outro fator importante é fazer com que o software seja construído de forma a preservar o investimento do cliente, ou seja, fazer com que o trabalho de mapeamento do domínio e de seus processos não se perca quando uma tecnologia específica precisar ser substituída (a camada de apresentação, por exemplo).

Um software que atende ao usuário é aquele que resolve os principais problemas do seu dia-a-dia de forma simples e objetiva e usa como base da comunicação a linguagem que o usuário domina: A linguagem de seu domínio.

Um software que atende ao fornecedor é aquele que visa não só a construção rápida do projeto, mas também práticas de engenharia e testes que possibilitem à equipe responsável pela manutenção do sistema tenham total autonomia na execução de suas tarefas. Usar práticas que facilitem a manutenção do software é fazer com que o investimento do cliente dure ao máximo, e todo profissional da área tem a responsabilidade de construir softwares pensando na próxima pessoa que irá manter o projeto.

Um software de qualidade é a base para um bom relacionamento com o cliente, com os usuários e com as equipes de desenvolvimento. Um software que não atende aos três stakeholders terá uma vida curta e será responsável por muitas dores de cabeça.

Cada área de estudo citada aqui direta ou indiretamente possui métodos e processos específicos para garantia da qualidade. É dever de todo profissional de desenvolvimento conhecer essas técnicas e utilizá-las da melhor forma possível visando obter um bom resultado ao final da jornada de desenvolvimento.

Aguardo feedbacks!

Recomendações de leitura:

Ubiquitous Language

• http://www.handersonfrota.com.br/ubiquitous-language/

DDD

• http://domaindrivendesign.org/
• http://www.infoq.com/minibooks/domain-driven-design-quickly
• http://www.infoq.com/articles/ddd-contextmapping

Integração contínua

• http://blog.caelum.com.br/2008/11/04/integracao-continua/
• http://blog.caelum.com.br/2010/01/18/integracao-continua-deploys-e-aprovacoes-sem-dores-de-cabeca-para-o-cliente/

Negociação de contratos

• http://improveit.com.br/xp/praticas/contrato

Veja também:

• http://www.heroisdati.com/praticas-ageis-sao-o-caminho-para-a-qualidade-de-software/

Albert Einstein

Nossa área de desenvolvimento de software é muito nova, e como consequência disso, ainda estamos aprendendo quais são as técnicas que funcionam e quais só atrapalham o dia-a-dia dos nossos projetos. É dever de todo profissional da área buscar meios para melhorar o nosso objetivo principal: Construir softwares que atendam aos clientes, aos usuários e às equipes de desenvolvimento.

Práticas ágeis são um meio e não um fim, não deve-se utilizar as técnias se não é evidente quais problemas elas tentam resolver, usar por usar não melhora em nada o resultado final do seu projeto. Você só deve usar essas práticas se realmente entender porquê elas são necessárias, e não porquê estão na moda.

Vamos observar os benefícios de algumas técnicas utilizadas no meio ágil:

Com TDD o programador cria o hábito de planejar suas tarefas antes de executá-las, isso se deve ao fato de que nessa técnica você começa pela elaboração de uma lista de testes para o artefato que será desenvolvido, e só depois começa a codificá-lo. Outro benefício do TDD é que o programador deve usar o seu código antes de implementá-lo, apesar de parecer estranho é uma quebra de paradigma excelente começar a codificação pelo teste e tomar as decisões de design do código antes de implementá-lo, isso reduz o retrabalho pois o programador percebe no início da codificação como ficará seu código ao final dela.

Muitos gestores ainda não acreditam nos benefícios da programação em par, sendo um dos motivos a sensação de perda de produtividade quando dois programadores são alocados para a mesma tarefa, essa sensação é falsa, pois existem uma série de fatores que devem ser levados em consideração quando falamos de produtividade. O ritmo de desenvolvimento da dupla é garantido pela  falta de distrações que um programador sozinho teria, dificilmente durante o desenvolvimento em par o “piloto” irá desviar do foco. Outro benefício da programação em par é a revisão que o “co-piloto” faz observando a codificação do piloto, muitos problemas podem ser identificados em tempo de codificação. A comunicação constante entre os programadores faz com que cada decisão seja mais bem pensada, e ainda traz um grande benefício: Dois membros da equipe vão conhecer aquele trecho do código, isso é essencial para contornar problemas de comunicação e troca de membros da equipe durante o desenvolvimento dos projetos.  A programação em par protege o investimento do projeto pois reduz a taxa de retrabalho da equipe e gera um código de qualidade superior, afinal, duas cabeças pensam melhor do que uma.

Desenvolver um software de forma iterativa e incremental traz uma série de benefícios, porém, também traz uma série de problemas. Desenvolver software em ciclos de tempo fechados faz com que cada minuto seja precioso, por isso, vários impedimentos são identificados ao longo do desenvolvimento e resolvidos a medida que as entregas são realizadas no final de cada ciclo. Como o desenvolvimento acontece em ciclos, a equipe de desenvolvimento pode aprender com os problemas enfrentados no ciclo anterior, isso permite que o processo de cada equipe possa ser melhorado continuamente, e essas melhorias sempre atacam um grande impedimento do clico anterior, ou seja, não são apenas melhorias por melhorias. Processos iterativos e incrementais também auxiliam a contornar o grande vilão dos projetos de software que é a mudânça de escopo, caso o cliente descubra uma nova necessidade  a mesma poderá ser implementada no próximo ciclo, já que o ciclo em desenvolvimento não deve ter seu objetivo alterado. Caso a necessidade do cliente mude (ou melhor, quando a necessidade do cliente mudar) e o ciclo desenvolvido não for mais necessário, o cliente só “perde” aquele ciclo, ou seja, o custo da alteração de escopo fica sendo o custo do desenvolvimento do novo ciclo. Outra característica interessante é que nessa forma de desenvolvimento os feedbacks dos usuários chegam muito mais cedo do que no modelo tradicional, já que no final do ciclo a equipe entrega um parte funcional do software, e já que o software entra em produção mais cedo o cliente também começa a usufruir dos benefícios do sistema mais cedo.

As técnicas ágeis são um meio para solucionar alguns dos problemas mais comuns dos ambientes de desenvolvimento como conhecemos (falta de comunicação, retrabalho, escopos rígidos, custos altos, falta de testes, etc.), elas propõem uma nova forma de trabalho, que tem se mostrado muito eficiente para equipes com o perfil adequado. Essas técnicas influenciam positivamente em todas as vertentes de avaliação da qualidade de um software desde que sejam aplicadas de forma correta.

Quer saber mais sobre as técnicas citadas? Seguem algumas referências:

Sobre TDD:

• TDD no Wikipédia
• Desenvolvimento orientado a teste – Por @viniciusteles
• Portal TDD
• Tudo sobre TDD – Por @victorhg
• Apresentação que utilizo em treinamentos – Por Fabrício Mattos
• Podcast TDD não existe

Sobre Programação em Par:

• Dicas sobre Programação em Par – Por @lucianofelix
• Par Programming no Wikipédia
• Programação em Par – Por @viniciusteles

Sobre desenvolvimento iterativo e incremental:

• Desenvolvimento iterativo e incremental no Wikipédia
• Escopo Iterativo e Incremental para o gerenciamento Ágil de requisitos – Por @visaoagil
• Scrum no Wikipédia
• Scrum - Por @viniciusteles
• Scrum Alliance
• Scrum.org

Qual a sua experiência sobre as técnicas ágeis? Você acha que elas são o caminho para aumentarmos a qualidade dos softwares que desenvolvemos?

Aguardo feedbacks!

Como já trabalhava há algum tempo com desenvolvimento, não foi tão difícil completar os skills que eram necessários para realizar a prova com segurança, mas como estudar não mata ninguém resolvi revisar uma série de aspectos do framework que não trabalhava com tanta frequência, foi a melhor coisa que fiz. Você realmente conhece o framework .net? Reflita um pouco, respire fundo e olhe os assuntos abordados nas provas conceituais e técnicas, você vai se surpreender.

As provas e certificações não são um fim, mas sim um meio de se obter o conhecimento necessário para dominar a plataforma ou ferramenta que você trabalha, sendo assim, a postura de profissionais que acham que suas certificações os diferenciam em alguma coisa não é uma verdade absoluta, o que realmente diferencia um profissional é o fato dele saber usar corretamente o seu “cinto de utilidades“, ou seja, saber aplicar corretamente o conhecimento adquirido ao longo de sua carreira. Participei de uma mesa redonda no grupo DFTestes onde vários profissionais apresentaram suas visões sobre o assunto, o resumo está disponível no site QualidadeBR, invista um tempo para refletir sobre os comentários feitos lá.

Vamos ao que interessa, seguem os links que me ajudaram a estudar para o exame 70-536:

Página oficial do exame
http://www.microsoft.com/australia/learning/exams/70-536.mspx

E-book
http://www.free-ebooks-download.org/free-ebook/dotnet/MCTS%20Dumps/mcpd-70-536.php

Links e artigos com o conteúdo da prova

Nessa relação constam artigos do MSDN, Israel Aece e Macoratti.

Developing applications that use system types and collections

Manage data in a .NET Framework application by using .NET Framework system types

Value Types (C# Reference)
Nullable Types (C# Programming Guide)
Reference Types (C# Reference)
Attributes (C# Programming Guide)
Generic Type Parameters (C#)
Exception Class
Boxing and Unboxing (C# Programming Guide)
TypeForwardedToAttribute Class (System.Runtime.CompilerServices)

TypeForwardedToAttribute at C# Online.NET (CSharp-Online.NET)Tipos de dados em .NET

Manage a group of associated data in a .NET Framework application by using collections

BitArray Class (System.Collections)
ICollection Interface (System.Collections)
Queue Class (System.Collections)
ReadOnlyCollectionBase Class (System.Collections)
LinkedList Generic Class (System.Collections.Generic)
EqualityComparer(T) Class (System.Collections.Generic)

Israel Aéce – Trabalhando com Coleções – Parte 1
Israel Aéce – Trabalhando com Coleções – Parte 2
Israel Aéce – Trabalhando com Coleções – Parte 3
Israel Aéce – Trabalhando com Coleções – Parte 4

Manage data in a .NET Framework application by using specialized collections

BitVector32 Structure (System.Collections.Specialized)

Implement .NET Framework interfaces to cause components to comply with standard contracts

IComparable Interface (System)
IDisposable Interface (System)
IConvertible Interface (System)
ICloneable Interface (System)
IEquatable(T) Interface (System)
IFormattable Interface (System)

Liberando os objetos de forma apropriada

Control interactions between .NET Framework application components by using events and delegates

Delegate Class (System)
EventArgs Class (System)
EventHandler Delegate (System)
delegate (C#)
How to: Combine Delegates (Multicast Delegates)(C#)

Simple and Multicast Delegates in C#.net
Linha de Código – Delegates e Eventos com C#.NET

Implementing service processes, threading, and application domains in a .NET Framework application

Implement, install, and control a service

Linha de Código – Por dentro da Base Classe Library – Capítulo 11 – Criando Serviços do Windows

Develop multithreaded .NET applications

Thread Class (System.Threading)
ThreadPool Class (System.Threading)
WaitCallback Delegate (System.Threading)

Foreground and Background Threads
Linha de Código – Usando Threads e Timer em ASP.NET
Israel Aéce – Threading – Parte 1
Israel Aéce – Threading – Parte 2
Israel Aéce – Threading – Parte 3
Israel Aéce – Threading – Parte 4

Embedding configuration, diagnostic, management, and installation features into a .NET Framework application

Embed configuration management functionality into a .NET Framework application

Linha de Código – Por dentro da Base Classe Library – Capitulo 3 – Utilização de Assemblies

Manage an event log by using the System.Diagnostics namespace

EventLog Class (System.Diagnostics)
How to: Create EventLog Component Instances
How to: Read Event Log Entries

Israel Aéce – Monitoramento e depuração de aplicações – Parte 1

Manage system processes and monitor the performance of a .NET application by using the diagnostics functionality of the .NET Framework

Process Class (System.Diagnostics)
PerformanceCounter Class (System.Diagnostics)
PerformanceCounterCategory Class (System.Diagnostics)
CounterCreationData Class (System.Diagnostics)
StackTrace Class (System.Diagnostics)
StackFrame Class (System.Diagnostics)

Retrieving Information About Processes
Process.GetProcessesByName Method (String) (System.Diagnostics)
How to: View Running Processes
How to: Investigate Libraries Loaded by Processes
Israel Aéce – Monitoramento e depuração de aplicações – Parte 2
Linha de Código – Manipulando processos através da classe System.Diagnostics.Process
How to get the Process Name in C#? C# Friends

Debug and trace a .NET Framework application by using the System.Diagnostics namespace

Debug Class (System.Diagnostics)
Classe Debugger (System.Diagnostics)
Classe Trace (System.Diagnostics)
TraceSource Class (System.Diagnostics)
SourceSwitch Class (System.Diagnostics)
CorrelationManager Class (System.Diagnostics)
TraceSwitch Class (System.Diagnostics)

Israel Aéce – Criando um DebuggerVisualizer
What is the difference between the Debug class and Trace class?
Israel Aéce – Monitoramento e depuração de aplicações – Parte 2
Israel Aéce – Monitoramento e depuração de aplicações – Parte 3
Israel Aéce – Monitoramento e depuração de aplicações – Parte 4
Israel Aéce – Monitoramento e depuração de aplicações – Parte 5
Usando técnicas de Trace e Debug – Tiago Colombo – .Net

Embed management information and events into a .NET Framework application

Retrieving Collections of Management Objects
WQL (SQL for WMI) (Windows)
Windows Management Instrumentation (Windows)
Win32_Environment Class (Windows)
Win32_Service Class (Windows)
SelectQuery Class (System.Management)
ManagementQuery Class (System.Management)
ManagementObjectSearcher Class (System.Management)
ManagementOperationObserver Class (System.Management)
CompletedEventHandler Delegate (System.Management)
ObjectReadyEventHandler Delegate (System.Management)

Implementing serialization and input/output functionality in a .NET Framework application

Serialize or deserialize an object or an object graph by using runtime serialization techniques

System.Runtime.Serialization Namespace ()
StreamingContext Structure (System.Runtime.Serialization)
FormatterServices Class (System.Runtime.Serialization)
FormatterConverter Class (System.Runtime.Serialization)
Formatter Class (System.Runtime.Serialization)
ObjectManager Class (System.Runtime.Serialization)
SerializationInfo Class (System.Runtime.Serialization)

Linha de Código – Por dentro da Base Classe Library – Capítulo 6 – Serialização

Control the serialization of an object into XML format by using the System.Xml.Serialization namespace

System.Xml.Serialization Namespace ()
XmlSerializer Class (System.Xml.Serialization)

Implement custom serialization formatting by using the Serialization Formatter classes

SoapFormatter Class (System.Runtime.Serialization.Formatters.Soap)
BinaryFormatter Class (System.Runtime.Serialization.Formatters.Binary)

Access files and folders by using the File System classes

Linha de Código – Por dentro da Base Classe Library – Capítulo 5 – Manipulando o sistema de arquivos

Manage .NET Framework application data by using Reader and Writer classes

StringReader Class (System.IO)
StringWriter Class (System.IO)
TextWriter Class (System.IO)
TextReader Class (System.IO)
StreamReader Class (System.IO)
StreamWriter Classe (System.IO)
Classe BinaryWriter (System.IO)
BinaryReader Classe (System.IO)
System.IO Namespace ()

VB.NET -  Lendo e escrevendo em arquivo Textos
Linha de Código – System.IO: Criando um arquivo usando Visual Studio.NET 2005

Compress or decompress stream information in a .NET Framework application and improve the security of application data by using isolated storage

System.IO.Compression Namespace ()
DeflateStream Class (System.IO.Compression)
GZipStream Class (System.IO.Compression)
IsolatedStorageFileStream Class (System.IO.IsolatedStorage)
IsolatedStorageFile Class (System.IO.IsolatedStorage)

Como: obter armazenamentos para o armazenamento isolado
Israel Aéce – Compressão de Arquivos no .NET
Macoratti – Compactando e Descompactando arquivos
Compactando e Descompactando Arquivos com a classe GZipStream

Improving the security of .NET Framework applications by using the .NET Framework security features

Implement access control by using the System.Security.AccessControl classes

System.Security.AccessControl Namespace ()
DirectorySecurity Class (System.Security.AccessControl)
FileSecurity Class (System.Security.AccessControl)
FileSystemSecurity Class (System.Security.AccessControl)
RegistrySecurity Class (System.Security.AccessControl)
AccessRule Class (System.Security.AccessControl)
AuthorizationRule Class (System.Security.AccessControl)
AuthorizationRuleCollection Class (System.Security.AccessControl)
CommonAce Class (System.Security.AccessControl)
CommonAcl Class (System.Security.AccessControl)
CompoundAce Class (System.Security.AccessControl)
GenericAce Class (System.Security.AccessControl)
GenericAcl Class (System.Security.AccessControl)
AuditRule Class (System.Security.AccessControl)
MutexSecurity Class (System.Security.AccessControl)
ObjectSecurity Class (System.Security.AccessControl)
SemaphoreSecurity Class (System.Security.AccessControl)

Implement a custom authentication scheme by using the System.Security.Authentication classes

System.Security.Authentication Namespace ()

Encrypt, decrypt, and hash data by using the System.Security.Cryptography classes

System.Security.Cryptography Namespace ()
DES Class (System.Security.Cryptography)
DESCryptoServiceProvider Class (System.Security.Cryptography)
SHA1CryptoServiceProvider Class (System.Security.Cryptography)
SHA1 Class (System.Security.Cryptography)
DSACryptoServiceProvider Class (System.Security.Cryptography)
DSA Class (System.Security.Cryptography)
HashAlgorithm Class (System.Security.Cryptography)
TripleDES Class (System.Security.Cryptography)
RC2CryptoServiceProvider Class (System.Security.Cryptography)
RC2 Class (System.Security.Cryptography)
CryptoConfig Class (System.Security.Cryptography)
CryptoStream Class (System.Security.Cryptography)
RandomNumberGenerator Class (System.Security.Cryptography)
MD5CryptoServiceProvider Class (System.Security.Cryptography)
MD5 Class (System.Security.Cryptography)
TripleDESCryptoServiceProvider Class (System.Security.Cryptography)
HMAC Class (System.Security.Cryptography)
CryptoAPITransform Class (System.Security.Cryptography)
CspParameters Class (System.Security.Cryptography)
RijndaelManagedTransform Class (System.Security.Cryptography)
RijndaelManaged Class (System.Security.Cryptography)
ProtectedData Class (System.Security.Cryptography)
ProtectedMemory Class (System.Security.Cryptography)
AsymmetricAlgorithm Class (System.Security.Cryptography)
SymmetricAlgorithm Class (System.Security.Cryptography)

Linha de Código – Por dentro da Base Classe Library – Capítulo 8 – Criptografia
Linha de Código – Por dentro da Base Classe Library – Capítulo 8 – Criptografia
Linha de Código – Por dentro da Base Classe Library – Capítulo 8 – Criptografia

Control permissions for resources by using the System.Security.Permission classes

Code Access Security
Code Groups
Evidence
Named Permission Sets
System.Security.Permissions Namespace ()
SecurityPermission Class (System.Security.Permissions)
PrincipalPermission Class (System.Security.Permissions)
Evidence Class (System.Security.Policy)
FileIOPermission Class (System.Security.Permissions)
StrongNameIdentityPermission Class (System.Security.Permissions)
UrlIdentityPermission Class (System.Security.Permissions)
DataProtectionPermission Class (System.Security.Permissions)
IsolatedStorageFilePermission Class (System.Security.Permissions)
IUnrestrictedPermission Interface (System.Security.Permissions)
SiteIdentityPermission Class (System.Security.Permissions)
StorePermission Class (System.Security.Permissions)
ReflectionPermission Class (System.Security.Permissions)
KeyContainerPermission Class (System.Security.Permissions)
System.Security.Policy Namespace ()
PermissionRequestEvidence Class (System.Security.Policy)
ApplicationTrust Class (System.Security.Policy)
ApplicationSecurityManager Class (System.Security.Policy)
ApplicationSecurityInfo Class (System.Security.Policy)
UnionCodeGroup Class (System.Security.Policy)
NetCodeGroup Class (System.Security.Policy)
FirstMatchCodeGroup Class (System.Security.Policy)
FileCodeGroup Class (System.Security.Policy)
CodeGroup Class (System.Security.Policy)
IIdentityPermissionFactory Interface (System.Security.Policy)
IMembershipCondition Interface (System.Security.Policy)
IApplicationTrustManager Interface (System.Security.Policy)
PolicyStatement Class (System.Security.Policy)
PolicyLevel Class (System.Security.Policy)

Israel Aéce – Utilizando Code Access Security – CAS – Parte 1
Israel Aéce – Utilizando Code Access Security – CAS – Parte 2
Israel Aéce – Utilizando Code Access Security – CAS – Parte 3
Code Access Security – Wikipedia, the free encyclopedia

Implementing interoperability, reflection, and mailing functionality in a .NET Framework application

Expose COM components to the .NET Framework and .NET Framework components to COM

Platform Invoke Data Types
Linha de Código – Por dentro da Base Classe Library – Capítulo 12 – Interoperabilidade com componentes COM

Implement reflection functionality in a .NET Framework application, and create metadata, Microsoft intermediate language (MSIL), and a PE file by using the System.Reflection.Emit namespace

AppDomain Class (System)
Type Class (System)
System.Reflection Namespace ()
System.Reflection.Emit Namespace ()
MethodInfo Class (System.Reflection)
MethodBase Class (System.Reflection)
MethodBody Class (System.Reflection)
Assembly Class (System.Reflection)
AssemblyName Class (System.Reflection)
BindingFlags Enumeration (System.Reflection)
Binder Class (System.Reflection)
AssemblyBuilder Class (System.Reflection.Emit)

Linha de Código – Consultando e invocando métodos dincamicamente usando Reflection
Linha de Código – Por dentro da Base Classe Library – Capítulo 13 – Reflection
Linha de Código – Por dentro da Base Classe Library – Capítulo 13 – Reflection
Linha de Código – Por dentro da Base Classe Library – Capítulo 13 – Reflection
Linha de Código – Por dentro da Base Classe Library – Capítulo 13 – Reflection

Send electronic mail to a Simple Mail Transfer Protocol (SMTP) server for delivery from a .NET Framework application

Linha de Código – Por dentro da Base Classe Library – Capítulo 10 – Envio de Mensagens (E-mails)

Implementing globalization, drawing, and text manipulation functionality in a .NET Framework application

Format data based on culture information

CultureInfo Class (System.Globalization)
CultureInfo.CurrentCulture Property (System.Globalization)
CompareInfo Class (System.Globalization)
RegionInfo Class (System.Globalization)
CultureAndRegionInfoBuilder Class (System.Globalization)
Using the CultureInfo Class
Formatting Numeric Data for a Specific Culture
Formatting Date and Time for a Specific Culture
Performing Culture-Insensitive String Comparisons

Using Custom Cultures—Using CultureAndRegionInfoBuilder at C# Online.NET (CSharp-Online.NET)
Israel Aéce – Globalização de Aplicações – Parte 1
Israel Aéce – Globalização de Aplicações – Parte 2
Israel Aéce – Globalização de Aplicações – Parte 3

Fique ligado, em breve estarão disponíveis outros guias de estudo.

Abraços!

Este blog é a saída que encontrei para apresentar idéias sobre a área e poder divulgar pesquisas, estudos e treinamentos. Não tenho como objetivo criar conteúdos exclusivos ou fazer propaganda, o objetivo deste blog é simplesmente ajudar a comunidade com informações técnicas e reflexões sobre práticas, metodologias e manias que fazem da nossa área uma das áreas mais interessantes para se atuar (se você não gosta de ficar acomodado ).

Como tenho uma série de artigos preparados e muito conteúdo off-line, grande parte das publicações terão temas técnicos sobre .net e outras plataformas, porém, não acredito que nossa área seja deficiente nesse aspecto, acredito que muitos dos nossos profissionais precisem aprender a olhar o todo independente do papel que desempenham na equipe, no projeto ou na empresa onde estão.

Como profissionais de desenvolvimento, precisamos conhecer sobre diversas áreas, entender e mapear processos, criar realidades nos sistemas de informação que muitas vezes funcionam melhor do que no mundo real. Ajudamos empresas a melhorar seus processos e a otimizar suas rotinas, sem falar que nosso trabalho cria vantagens competitivas e também reduz drasticamente custos. Realmente somos heróis do mundo moderno, porém, infelizmente somos desconhecidos, somos desenvolvedores de software.

A partir de hoje vou usar outro twitter para publicar novidades sobre a área, irei usar o twitter do blog @heroisdati.

Fiquem ligados e contribuam com feedbacks.

Abraços!