Rodrigo Vidal PSD – MCPD – MCTS – MCP / Arquitetura e Desenvolvimento de Software

31ago/101

F.I.R.S.T Principles about Tests

podio

Olá pessoal, mantendo a série sobre Testes de Software, no post sobre Testes Unítários e Testes de Integração falei sobre algumas caracteristicas que considero que os testes devem possuir.

Neste post venho mostrar os Principios FIRST, que foram enumerados pelo Uncle Bob em seu livro Clean Code. Achei bem interessante, e como nós Devs geralmente adoramos uma sigla está ai mais uma referente a boas praticas sobre testes.
Considero estas propriedades essenciais para bons testes.

Fast – Testes devem ser rapidos. Devem executar rapidamente. Quando testes executam lentamente, voce nao irá querer roda-los com frequência. Se você não os roda com frequência, você não encontrará o problema cedo o suficiente para que possa corrigi-los com facilidade.  Você não se sentirá livre para limpar o código. Eventualmente o código começará a apodrecer.

Independent – Testes não devem depender uns dos outros. Um teste não deve configurar condições para o próximo teste. Voce deve estar apto a executar cada teste de forma independente e em qualquer ordem. Quando testes dependem uns dos outros, então a primeira falha, desencadeará uma sucessão de falhas, tornando o diagnóstico dificil e escondendo a provável causa.

Repeatable – Testes devem ser repetiveis em qualquer ambiente. Você deve poder executar em um ambiente de produção, quality assurance, e no seu notebook enquanto está a caminho de casa em um trêm sem rede. Se os seus testes nao são repetiveis em qualquer ambiente, então voce sempre terá uma desculpa quando eles falharem. Você também estará impossibilitado de rodar seus testes quando o ambiente não estiver disponível.

Self-Validating – Testes deve ter uma saída logica. Ou eles passam ou falham. Voce não deve ter que ler um arquivo de log, por exemplo, para saber se seus testes passaram. Você não deve ter que manualmente comparar dois arquivos de texto para saber se passaram. Se os testes não são auto-validáveis, então a falha se torna subjetiva e rodar os teste necessita de uma longa validação manual.

Timely – Testes devem ser escrito em um momento oportuno. Testes unitários podem ser escritos antes do código de produção que faria os testes passarem, se estiver sendo utilizada uma técnica chamada de Test Driven Development. Se você escreve testes após o codigo de produção, você pode acabar aceitando que seu código ficou muito dificil de ser testado, e não testá-lo. Por fim você pode não projetar o seu código para ser testável.

Na minha opinião estes principios são os primeiros principios para construção de bons testes e deve-se evitar violá-los. Isto facilitará a elaboração, execução e manutenção de sua especificação. Claro que existem outros principios importantes. E estes serão abordados em futuros posts.

Abraço pessoal!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
23ago/100

TechEd Brasil 2010 – Agenda

Olá pessoal, segue minha agenda para o TechEd Brasil 2010. Ela ainda está na versão 1.0 e está sujeita a mudanças.

Programação do dia 13/09/2010
13:45 – 15:00
Título: Desenvolvendo para Azure
Palestrante (s): Otavio Pecego Coelho,

15:30 – 16:45
Título: Arquitetura de Soluções com o Windows Server AppFabric, WCF e WF – Patterns de Aplicações, Serviços e Workflows
Palestrante (s): Waldemir Cambiucci,

17:15 – 18:30
Título:Green IT na Prática: O que o gerente de TI, o Administrador de Rede e o Desenvolvedor podem fazer a respeito?
Palestrante (s): Fabio Hara, Rodrigo Dias, Rogerio Cordeiro

Programação do dia 14/09/2010
09:00 – 10:15
Título: SQL Azure - Cenários de Uso, Migração e Operação
Palestrante (s): Waldemir Cambiucci

10:45 – 12:00
Título: Segurança no Desenvolvimento para Windows Azure
Palestrante (s): Weber Ress

13:45 – 15:00
Título: Aproveitando ao máximo as ferramentas do Visual Studio 2010 para Silverlight e WPF
Palestrante (s): Kelps Leite de Sousa

15:30 – 16:45
Título: Implementando Serviços RESTful usando o Microsoft .NET Framework
Palestrante (s): Israel Aece,

17:15 – 18:30
Título: Aplicações WEB com Silverlight 4 fora do Browser
Palestrante (s): Djonatas Tenfen, Rogerio Cordeiro

Programação do dia 15/09/2010
09:00 – 10:15
Título: Usando o pattern MVVM (Model-View-ViewModel) para desenvolvimento em WPF e Silverlight
Palestrante (s): Bruno Sonnino

10:45 – 12:00
Título: Estratégias para otimizar a concorrência dentro do Microsoft SQL Server 2008 R2
Palestrante (s): Luiz Felipe Ribeiro Pimenta

13:45 – 15:00
Título: Criando Rich Internet Applications (RIA) com Silverlight 4 e WCF RIA Services
Palestrante (s): Kelps Leite de Sousa

15:30 – 16:45
Título: Paralelismo no .Net 4.0: Patterns, dicas e truques
Palestrante (s): Otavio Pecego Coelho

17:15 – 18:30
Título: Tudo o que você precisa saber sobre Data Mining
Palestrante (s): Roberval Ranches

Quem quiser trocar ideias sobre as palestras, e marcar algo, fique a vontade para entrar em contato comigo.

Abraço! E nos vemos no TechEd!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
20jul/101

Working with Stubs

Olá pessoal, vou seguir com esta série sobre Testes de Software. E hoje vamos conversar um pouco sobre Stubs.

Vamos analisar o seguinte cenário: Temos o seguinte Teste.

        [TestMethod]
        public void HasCreditInCard_ForAGivenCard_ReturnsTrue()
        {
            var analyzer = new CreditAnalyzer();
            bool result = analyzer.HasCreditInCard("000.000.000");
 
            Assert.IsTrue(result);
        }

Como podemos perceber desejamos testar o método HasCreditInCard da classe CreditAnalyzer.

Dada a  implementação:

    public class CreditAnalyzer
    {
        public bool HasCreditInCard(string cardNumber)
        {
            CreditService manager = new CreditService();
            return manager.HasCredit(cardNumber);
        }
    }
 
    public class CreditService
    {
        public bool HasCredit(string cardNumber)
        {
            //Real implementation
	    //Call WCF Service
            return true;
        }
    }

No entanto, notamos que este método possui uma dependência externa para um serviço externo(WCF) que está sendo utilizado por um Serviço de Crédito.

Primeiramente vamos definir o que é uma dependência externa.

Dependencia externa é um objeto no seu sistema, que sua “unidade sobre teste”  interage, e sobre o qual não possui controle. Como threads, memoria, arquivos, tempo, serviços e etc.

O stub é um substituto controlável para uma dependência existente (ou um colaborador) no sistema. Usando um Stub, voce pode testar seu código sem lidar diretamente com esta dependência.

O problema aparece, uma vez que este teste depende de um serviço, então estamos na verdade utilizando um teste de integração, e como ja sabemos temos problemas associados: testes lentos para executar, precisam de configuração, testam multiplas regiões de código, etc.

Para quebrarmos esta dependencia externa podemos seguir alguns passos:

1 - Encontre a Interface que o método sobre teste opera. No nosso exemplo a Interface é o Serviço de Crédito.

2 – Se a interface estiver diretamente conectada ao método que estamos testando, e neste caso está invocando diretamente o Service, torne o código testável adicionando uma Camada de Indireção à Interface. No nosso caso podemos mover a chamada direta, para uma classe separada.
3 – Troque a implementação atual da interface por outro que você possa controlar. No nosso caso, trocaremos a instância da classe que nosso método chama, por uma classe Stub, que podemos controlar, dando ao nosso código de teste controle sobre nossas dependências externas.

Nosso substituto não irá conversar com o Serviço como a implementação original, ele quebra essa dependencia.. Nós não estamos testando a classe que fala com o Service, mas sim o código que utiliza esta classe.

image

Introduzindo uma camada de indireção para evitar a dependencia ao WCF Service. O código que chama este serviço esta separado na classe CreditService, que será substituida pelo Stub.

image

Então adicionamos uma interface. Ela irá permitir abstrair as operações realizadas pela classe CreditService.

Agora podemos dizer para nossa classe a ser testada (CreditAnalyzer), pode lidar com qualquer tipo de CreditService, sem conhecer sua implementação. Isso pode ser feito utilizando uma classe base ou uma interface.

   public class CreditService : ICreditService
    {
        public bool HasCredit(string cardNumber)
        {
            //Real implementation
            //Do task
            //Do more task
            return true;
        }
    }
 
    public interface ICreditService
    {
        bool HasCredit(string cardNumber);
    }
 
    public class CreditAnalyzer
    {
        public bool HasCreditInCard(string cardNumber)
        {
            ICreditService manager = new CreditService();
            return manager.HasCredit(cardNumber);
        }
    }

Simplesmente criamos uma interface com um método HasCredit e o CreditService implementa esta interface. Agora podemos substituir a implementação real do CreditService pelo nosso StubCreditService.

   public class StubCreditService : ICreditService
    {
        public bool HasCreditInCard { get; set; }
        public bool HasCredit(string cardNumber)
        {
            return HasCreditInCard;
        }
    }

Legal mas nosso método HasCreditInCard continua chamando a implementação real diretamente. Uma solução dentre várias seria injetar o stub na classe que está sendo testada. Para este exemplo utilizarei injeção no construtor.

   [TestClass]
    public class CreditAnalyzerTest
    {
        [TestMethod]
        public void HasCreditInCard_ForAGivenCard_ReturnsTrue()
        {
            var stubManager = new StubCreditService();
            stubManager.HasCreditInCard = true;
 
            var analyzer = new CreditAnalyzerInjection(stubManager);
            bool result = analyzer.HasCreditInCard("000.000.000");
 
            Assert.IsTrue(result);
        }
    }

Desta forma com essa implementação do analisador ficaria da seguinte forma utilizando Injeção de Dependência.

    public class CreditAnalyzer
    {
        private ICreditService manager;
 
        public CreditAnalyzer(ICreditService manager)
        {
            this.manager = manager;
        }
 
        public bool HasCreditInCard(string cardNumber)
        {
            return manager.HasCredit(cardNumber);
        }
    }

Vimos como criar Stubs para eliminar dependências no código. usando interfaces e herança. Um Stub pode ser injetado no código de muitas maneiras. O mais importante é localizar a melhor camada de indireção a ser criada, para que voce possa injetar seu Stub.  Quanto mais fundo você for nas camadas de interação mais dificil será entender e manter o teste, quanto mais proximo da superficie do objeto que está sendo testado, mais facil.  Mas voce também poderá estar abrindo mão do seu poder de manipular o ambiente para testar o objeto.

Meu objetivo era explicar basicamente como funcionam Stubs. E como utiliza-los para eliminar dependências no seu código.

Espero que tenham gostado, e aguardo feedbacks.

Abraço pessoal!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
12jul/102

Unit and Integration Tests

Muitos desenvolvedores confundem a definição de Testes de Unidade e Testes de Integração, então vamos entender um pouco melhor suas diferenças Testes de Unidade ou Unit Tests é um conceito antigo em desenvolvimento de software. Kent Beck introduziu este conceito no SmallTalk na década de 70. Beck quis mostrar que esta era uma das melhores formas para se aumentar a qualidade do código enquanto se obtia um profundo conhecimento a respeito do requisitos funcionais do sistema sobre teste.

Teste de Unidade ou Unit Test

como também é conhecido é um trecho de código que executa outro trecho de código e verifica a exatidão de alguns pressupostos. Caso estes pressupostos estejam errados, o teste falha, caso estejam corretos, o teste passa. Uma unidade é um método ou uma função.

Propriedades de um bom Teste Unitário:

  • Deve ser automatizável e repetitível
  • Deve ser facil de implementar
  • Uma vez escrito, deve ser possivel executa-lo futuramente
  • Todos deve estar aptos a executa-lo
  • Deve executar rapidamente

Para exemplo de código unitário utilizarei o Template padrão de uma aplicação asp.net MVC 2 criado com o Visual Studio 2010.

        [TestMethod]
        public void Index()
        {
            // Arrange
            HomeController controller = new HomeController();
 
            // Act
            ViewResult result = controller.Index() as ViewResult;
 
            // Assert
            ViewDataDictionary viewData = result.ViewData;
            Assert.AreEqual("Welcome to ASP.NET MVC!", viewData["Message"]);
        }

Explicando o código: Esta [TestClass] testa a classe HomeController, e seu [TestMethod] testa o métodoIndex().
No Arrange é instanciado um objeto do tipo Homecontroller. Em Act é invocado o métodoIndex() e seu valor deretorno armazenado na variavel result. Posteriormente no Assert é comparado o Valor Esperado, com o Valor Obtido.

No entanto o que faz este teste ser unitário e não de integração é o fato da métodoIndex() ser declarado da seguinte forma na classe HomeController.

        public ActionResult Index()
        {
            ViewData["Message"] = "Welcome to ASP.NET MVC!";
 
            return View();
        }

Nota-se que o métodoIndex() não se integra a nenhuma outra região de código, por exemplo a um Serviço, ou a um Repositório. Ou seja, não há dependência externa.

Um Teste Unitário, deve ser confiável, legível e manutenível, testando uma única unidade de código. Keep it simple!

Testes de Integração ou Integration Tests

são testes em que duas ou mais partes de software e/ou hardware dependentes são combinados e testados como uma única unidade. Ou seja,um teste deste tipo utiliza de varias unidades de código que trabalham juntos, para avaliar um ou mais resultados esperados do software.

Exemplo(modificado):

        [TestMethod]
        public void LogOff_LogsOutAndRedirects()
        {
            // Arrange
            AccountController controller = GetAccountController();
 
            // Act
            ActionResult result = controller.LogOff();
 
            // Assert
            Assert.IsTrue((controller.FormsService).SignOut_WasCalled);
        }

Este método de teste efetua a chamada a um método deLogOff implementado na classe AccountController da seguinte forma:

        public ActionResult LogOff()
        {
           AuthenticationService FormsService = new AuthenticationService();
           FormsService.SignOut();
 
            return RedirectToAction("Index", "Home");
        }

Ou seja este método depende de uma classe de Serviço que tem a atribuição de efetivamente realizar o logOff. A classe AccountController está sendo testada juntamente com a classe de Serviço(FormsService) como uma única unidade. O resultado é que caso o teste falhe, todos os componentes envolvidos falham como um time,  o que pode dificultar a correção do problema que efetivamente causou a falha de toda a operação.  Logo este teste é de Integração.

UnitAndIntegrationTest

Resumindo: Um teste de integração exercita várias unidades de código que trabalham juntos para avaliar um ou mais resultados esperados de um software, enquanto um teste unitário exercita e teste uma unidade de código em isolamento.

Espero que tenha ficado claro o conceito.

Qualquer dúvida ou critica é só comentar.

Abraço

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
28mai/100

Resultado do Coding Dojo – DotNetArchitects RJ

DotNetArchitects - Coding Dojo

Olá pessoal,
venho publicar o resultado do Coding Dojo do DotNetArchitects Rio de Janeiro .Primeiro gostaria de dizer que foi FANTASTICO! Por mais que eu ja tenha participado de outros Dojos, este foi diferente, experiencia incrivel trocada e compartilhada!  O problema a ser solucionado foi o FizzBuzz, que é um problema simples ideal para primeiro dojo oficial. No entanto o problema se mostrou bem interessante para darmos ênfase a conceitos chaves do TDD.

  Abaixo segue o código com os Testes:

namespace FizzBuzzTest
{
    [TestClass]
    public class FizzBuzzTest
    {
        [TestMethod]
        public void Recebe_1_e_Retonar_1()
        {
            var lista = new[] { "1" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 1 }));
        }
 
        [TestMethod]
        public void Recebe_2_e_Retonar_2()
        {
            var lista = new[] { "2" };
            CollectionAssert.AreEqual(lista, FizzBuzz( new int[] { 2 }));
        }
 
        [TestMethod]
        public void Recebe_3_e_Retonar_fizz()
        {
            var lista = new[] { "fizz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 3 }));
        }
 
        [TestMethod]
        public void Recebe_4_e_Retonar_4()
        {
            var lista = new[] { "4" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 4 }));
        }
 
        [TestMethod]
        public void Recebe_5_e_Retonar_Buzz()
        {
            var lista = new[] { "buzz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 5 }));
        }
 
        [TestMethod]
        public void Recebe_15_e_Retonar_FizzBuzz()
        {
            var lista = new[] { "fizzbuzz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 15 }));
        }
 
        [TestMethod]
        public void Recebe_9_e_Retonar_Fizz()
        {
            var lista = new[] { "fizz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 9 }));
        }
 
        [TestMethod]
        public void Recebe_10_e_Retonar_Buzz()
        {
            var lista = new[] { "buzz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 10 }));
        }
 
        [TestMethod]
        public void Recebe_45_e_Retorna_FizzBuzz()
        {
            var lista = new[] { "fizzbuzz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 45 }));
        }
 
        [TestMethod]
        public void Recebe_lista_1_2_retorna_1_2()
        {
            var lista = new[] { "1", "2" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] {1,2}));
        }
 
        [TestMethod]
        public void Recebe_lista_1_2_3_retorna_1_2_Fizz()
        {
            var lista = new[] { "1", "2","fizz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 1, 2, 3 }));
        }
 
        [TestMethod]
        public void Recebe_lista_1_2_3_4_5_15_retorna_1_2_Fizz_4_Buzz_FizzBuzz()
        {
            var lista = new[] { "1", "2","fizz", "4", "buzz", "fizzbuzz" };
            CollectionAssert.AreEqual(lista, FizzBuzz(new int[] { 1, 2, 3, 4, 5, 15 }));
        }
}

E a implementação:

 private string[] FizzBuzz(int[] p)
        {
            var lista = new List();
            foreach (var item in p)
            {
                if ((item % 3 == 0) && (item % 5 != 0))
                    lista.Add("fizz");
                else if ((item % 5 == 0) && (item % 3 != 0))
                    lista.Add("buzz");
                else if ((item % 3 == 0) && (item % 5 == 0))
                    lista.Add("fizzbuzz");
                else
                    lista.Add(item.ToString());
            }
            return lista.ToArray();
        }

Também gostaria de agradecer à Perlink e ao Fernando Bichara por apoiar e patrocinar a reunião do grupo.

Fizemos uma retrospectiva e os seguintes pontos foram levantados para futuros Dojos:

O que foi bom?

  • Muitos aprenderam novos conceitos
  • Troca de conhecimento
  • Lanche
  • Estrutura
  • Primeiro Dojo Oficial do DotNetArchitects RJ
  • O problema de facil entendimento
  • Bom humor
  • Ambiente inclusivo
  • Refactoring
  • O Luan não chegou atrasado(um milagre!)
  • O problema foi resolvido
  • Pós-Dojo no Devassa Largo do Machado

O que pode melhorar?

  • Conversa paralela
  • o teclado
  • Muita gente se inscreveu e não foi!
  • Alguns estavam presentes e nao quiseram colocar a mão no código
  • Podia ir até mais tarde
  • Fred na foto (ahahahhaha!)

Bom pessoal é isso, ficamos muito felizes com o resultado que este Dojo gerou, e acredito que foi de grande valia para todos os participantes.
Espero também que o próximo não demore!

E claro, nao deixem de participar nos comentários. E voce que não foi, PERDEU!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
17mai/101

.NetArchitects RJ – 2º Coding Dojo

lastsamuraiOlá pessoal,

Estou aqui para falar do nosso segundo Coding Dojo. Para quem nunca participou de um Coding Dojo, não se preocupe, o ambiente é extremamente inclusivo. É um oportunidade única para conhecer Test Driven Development ( #TDD) na prática, utilizando programação pareada, e o mais recente ambiente de desenvolvimento da Microsoft, o Visual Studio 2010. A linguagem utilizada será o C# 4

Confira e faça sua incrição aqui:
http://spreadsheets.google.com/viewform?formkey=dEoyRE1KZXNEcUlyeDA0X3dkeUtPUkE6MQ

 Horario: 18:30
Data: 24/05/2010
Local: Empresa: Perlink, Av. Presidente Vargas, 309 - 19º andar - Centro - RJ 

Não existem pré-requisitos para participar, basta ter vontade e comparecer!

Saiba mais sobre Coding Dojo aqui.

Abraços, nos vemos lá!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
21abr/100

DotNetArchitects – Community Launch RJ – Visual Studio 2010

 DotNetArchitects_logo

Olá pessoal,

primeiramente gostaria de justificar minha ausencia no blog no último mês. Estive organizando o evento do DotNetArchitects para o Community Launch, e isso demandou muito do meu tempo. No entanto agora voltarei com força total para continuar com as postagens sobre assuntos muito interessantes que já estão na minha pauta.

Bom então vamos falar um pouco do evento:
Foram 8 horas de evento contemplando as principais funcionalidades do principal lançamento do dia 12 de Abril, o Visual Studio 2010, sobre um olhar de Arquitetura de Software. Contamos com 8 palestrantes.

As palestras foram as seguintes:

Novidades do Visual Studio 2010 – Alexandre Bispo
Entity Framework 4.0 – Vinicius Quaiato (SP)
ASP.NET 4.0 – Sidney Filho
ASP.NET MVC 2 – Alexandre Valente
MEF Managed Extensibility Framework – Fernando Bichara
TDD Test Driven Development – Christian Cunha
ALM Application Lifecycle Management – Rodrigo Vidal
Manipulação de arquivos Office 2010 com OpenXML – Carlos Eduardo Ferreira

Tivemos presença forte da comunidade .NET do Rio de Janeiro, que vieram havidos por conhecimento na mais nova plataforma de desenvolvimento da Microsoft. Foram muitas perguntas, duvidas e ideias que surgiram ao decorrer de cada palestra e cada nova funcionalidade mostrada. O evento foi marcado pela forte determinação do time para faze-lo acontecer. Noites sem durmir, e mudanças até o ultimo minuto. O Resultado disso? Um evento fantastico, organizado, sem atrasos, perfeito. Foi uma experiencia unica que tenha certeza que nenhum de nós iremos esquecer.

Não podemos esquecer de agradecer aos nossos patrocinadores: WhiteFox, Infnet, Microsoft e Rcosta, assim como nossos palestrantes que preparam palestras  alta padrão técnico e visual.

Seguem algumas fotos abaixo, o restante pode ser encontrado meu Flickr:
http://www.flickr.com/photos/rodrigovidal/sets/72157623894180214/

Utilizamos a hashtag: #CLRJ e o Twitter bombou! Com forte participação do Saulo que cobriu o evento de ponta a ponta com seus tweets. A Infnet contava com rede WIFI então os presentes também puderam participar!

Foram sorteados muitos brindes e houve também o sorteio de uma licença de Resharper cedida pelo Giovanni Bassi.

Gostaria de agradecer também à BrasilDotNet(Brasilia) e à DEVGoias.NET pelo envio de brindes. E a presença do Bruno Kenj da BrasilDotNet, e do Palestrante Vinicius Quaiato de São Paulo, pela excelente contribuição para este evento.

 

DSC00184 DSC00187 DSC00154 DSC00161 DSC00168  DSC00170 DSC00172 DSC00182

Aqui segue alguns feedbacks do pessoal que foi ao evento:

alexandre costa: As palestras foram muito boas....
allan silva: Sensacional. Palestras desse nível deveriam acontecer com mais frequência, parabéns a todos que colaboraram para esse evento.
thiago: Muito bom! Deveriam ocorrer mais eventos desse tipo aqui no Rio.
igor tosoba: Também achei muito bom o evento!! Parabéns aos palestrantes!
roberta arcoverde: Só queria reforçar que o evento foi realmente muito legal! Vi todas as palestras e adorei!
renal cabral: Foi muito bom mesmo cara... show! acompanhei do início ao fim e adorei! =)

É isso pessoal, obrigado a todos!

E até a proxima!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
15mar/100

.NetArchitects RJ – Coding Dojo

dnarj_biggerOlá pessoal,

Nesta quarta-feira dia (17/03/2010) acontecerá o primeiro dojo do DotNetArchitects Rio de Janeiro!
Será imperdivel! O Dojo será em conjunto com o #DojoRio onde dojos são realizados toda quarta-feira, utilizando diversas linguagens de programação e puro TDD.

É a primeira vez que o DojoRio irá receber como linguagem o C#. E quem vai levar isso para lá? Será o DotNetArchitects e você que com certeza não vai faltar! Logo esperem um networking fantastico com profissionais que trabalham com as mais diversas tecnologias, Ruby, Python, Javascript, Java, .NET entre outras!

O endereço é:
Rua Teotônio Regadas 26 sala 201 - Lapa - Rio de Janeiro
Ao lado da sala Cecília Meireles, próximo ao Metrô Cinelândia

Conto com a presença de todos do DNARJ. E vamos fazer o melhor dojo que o Rio de Janeiro já viu!

Para informações em tempo real siga o @NetArchitectsRJ no twitter!

Abraço pessoal!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
7mar/103

Separation of Concerns – XHTML, CSS e JavaScript

Hoje venho falar de um assunto que considero de extrema importancia e ignorado por grande parte dos desenvolvedores web. A separação de responsabilidades entre XHTML, CSS e Javascript. Os dias passam e eu continuo a ver desenvolvedores escrevendo códigos que ignoram completamente os Padrões Web, que eu diria essenciais para garantir um código legivel para a camada de apresentação da sua aplicação.

A seguir segue um exemplo de código para demonstrar o pior caso:

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>">
<head>
    <title>Separation of Concerns - JavaScript Inline</title>
 
    <script src="Scripts/jquery-1.3.2.js"></script>
 
    <style type="text/css">
        h1{color:Blue;}
    </style>
</head>
<body>
    <h1 id="titulo">Separation of Concerns</h1>
    <button type="button" onclick="document.getElementById('titulo').style.color='red';">
        Alterar Cor
    </button>
</body>
</html>

Este código viola um dos principios fundamentais dos Padrões Web que determina a sepação total entre a estrutura de marcação, apresentação e comportamento. Ele consiste em inserir um script dentro da marcação HTML. Esta prática gera um imenso custo de manutenção ao desenvolvedores e prejudica a legibilidade do mesmo, por misturar as responsabilidades das três camadas.
Infelizmente esta prática ainda é amplamente utilizada.

A seguir uma outra solução para o mesmo problema:

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>">
<head>
    <title>Separation of Concerns</title>
 
    <script src="Scripts/jquery-1.3.2.js"></script>
    <script>
        function changeColor() {
            document.getElementById('titulo').style.color = 'red';
        }
    </script>
    <style type="text/css">
        h1{color:Blue;}
    </style>
</head>
<body>
    <h1 id="titulo">Separation of Concerns</h1>
    <button type="button" onclick="changeColor();">
        Alterar Cor
    </button>
</body>
</html>

Esta técnica apresenta uma melhoria em relação à anterior. Nesta é definida uma função javascript que pode ser reutilizada por varios botões dentro de uma mesma pagina. Pode-se também colocar esta função em um arquivo separado e linka-lo para diversas paginas que desejem utiliza-la.
No entanto está forma está longe de ser a ideial pois ainda continua a misturando responsabilidades e você possue uma função dentro do seu código HTML que só deveria conter marcação. Caso voce mude o nome da função, por exemplo, você necessariamente precisará encontrar todos os botões da sua aplicação que fazem uso desta e atualiza-los.

Uma terceira solução seria:

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>">
<head>
    <title>Separation of Concerns</title>
 
    <script src="Scripts/jquery-1.3.2.js"></script>
    <script>
        window.onload = function () {
            document.getElementById('botao').onclick = changeColor;
        }
 
        function changeColor() {
            document.getElementById('titulo').style.color = 'red';
        }
    </script>
 
    <style type="text/css">
        h1{color:Blue;}
    </style>
 
</head>
<body>
    <h1 id="titulo">Separation of Concerns</h1>
    <button id="botao" type="button">
        Alterar Cor
    </button>
</body>
</html>

Esta é a ideal. A marcação HTML não apresenta vestigios de scripts. No entanto uma boa prática é colocar os códigos de script e estilização em arquivos separados, .js e .css respectivamente para haver também uma separação entre os documentos e aumentar a reutilização dos códigos, linkando-os para as paginas que os utilizarão. Uma vantagem desta técnica é que scripts referenciados vão para o cache da máquina do usuário aumentando assim o desempenho de script não triviais ou de alta complexidade.

No entanto tomei a liberdade de apresentar uma quarta solução que será tema de um post futuro que utiliza JQuery:

<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>">
<head>
    <title>Separation of Concerns</title>
 
    <script src="Scripts/jquery-1.3.2.js"></script>
    <script>
        $(document).ready(function () {
            $('#botao').click(function () {
                $('#titulo').css('color', 'red');
            });
        });
    </script>
 
    <style type="text/css">
        h1{color:Blue;}
    </style>
 
</head>
<body>
    <h1 id="titulo">Separation of Concerns</h1>
    <button id="botao" type="button">
        Alterar Cor
    </button>
</body>
</html>

Uma das vantagens da utilização da JQuery ao invés de soluções comuns JavaScript é que ela nao permite misturar script com marcação HTML. Isso quer dizer que ela é mais aderente aos padrões web e dificulta que desenvolvedores menos experientes misturem as responsabilidades.

Até a próxima pessoal!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
21fev/103

Visual Studio + Internet Explorer 8 – Debug Problem

InternetExplorer 8 e Visual Studio
Olá pessoal,
Essa semana me deparei com um problema e achei interessante compatilhar com vocês. O problema consiste em o Debug Mode do Visual Studio simplesmente não funcionar com o Internet Explorer 8, ou seja, apesar de você colocar um breakpoint, por exemplo, no código, este era ignorado e nada acontecia.

O IE8 tem uma função chamada Loosely-Coupled Internet Explorer (LCIE) que faz com que este rode em multiplos processos. O resultado disso? O Debug do VS se perde e não sabe qual processo depurar.

Para resolver este problema siga os seguintes passos:

1)  Abra o CMD e execute RegEdit;
2)  Procure por  HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet Explorer -> Main;
3)  Adicione um DWORD nesta chave chamada TabProcGrowth;
4)  Atribua 0 (valor numérico ZERO) para TabProcGrowth;

É isso pessoal, espero que seje útil para alguem que tenha este problema.

Abraço e até a próxima!

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)