Essa é uma continuação do post anterior:

Testando o banco de dados: com Infra Microsoft

Nesse vou apresentar a mesma solução, mas usando outras ferramentas, quase todas open source. Por isso eu quero dizer tudo mesmo, só vou manter o Visual Studio de padrão.

Vamos ao cardápio:

Todo o projeto está no BitBucket para download. Você pode baixá-lo aqui e vê-lo online aqui.

Vamos começar pelos testes. Vou continuar no estilo AAA para testar:

using ClassLibrary1;
using NHibernate;
using MbUnit.Framework;

namespace TestProject1.Testes
{
    [TestFixture]
    public class TesteConsulta : TesteBase
    {
        private const int IdParaConsultar = 1;
        private ISession _session;
        private Produto _produtoEncontrado;

        [SetUp]
        public void Initialize()
        {
            Arrange();

            Act();
        }

        private void Arrange()
        {
            _session = Contexto.SessionFactory.OpenSession();
        }

        private void Act()
        {
            _produtoEncontrado = _session.Get<Produto>(IdParaConsultar);
        }

        [Test]
        public void ExisteNoBD()
        {
            Assert.IsNotNull(_produtoEncontrado);
        }
        [Test]
        public void TemNomeCorreto()
        {
            Assert.AreEqual("meu nome", _produtoEncontrado.Nome);
        }
    }
}

O primeiro a notar é que estamos usando MbUnit, como framework de testes. Ele é o responsável pelos atributos TestFixture na classe e Setup e Test nos métodos. O Gallio é parte do MbUnit (ou vice versa) e roda os testes. Ao rodar este é o resultado:

image

Esse resultado é obtido rodando com o TestDriven.Net. Com ele, posso clicar em qualquer lugar e rodar qualquer teste. Fica muito fácil, e como ele é especializado em rodar testes unitários, ele roda um pouco mais rápido que o runner do MSTest. Veja como rodar com TDD.Net na classe:

image

Mais fácil impossível, né? E dá para rodar também via Powershell:

Rodando:

image

Terminou de rodar, resultados:

image

O resultado é apresentado também com um relatório HTML. Publiquei o relatório de uma rodada completa de testes aqui no blog se alguém quiser dar uma olhada no resultado. O legal é que dá pra ver até os sqls gerados pelo NHibernate.

Se rodarmos todos os testes, o resultado é esse:

image

E para isso, basta clicar no projeto e mandar rodar:

image

Ok, chega de telinhas, vamos voltar para o teste.

Estamos usando NHibernate, e a sessão do NH (análoga ao contexto do Entity Framework), é aberta via SessionFactory, que está armazenada em uma classe chamada contexto, em uma propriedade estática:

public class Contexto
{
    public static ISessionFactory SessionFactory { get; set; }
}

Esse código seria usado também pela aplicação real, além dos testes. Estamos só reaproveitando. Logo mais vou mostrar como essa variável é configurada.

O método de ação bate no NH, que bate no banco, e obtem o produto com Id igual a 1. Esse é o método Act.

Os testes são verificações simples da existência do produto, e de sua propriedade Nome.

Tenho testes para exclusão e inclusão também. Esse é o de exclusão:

[TestFixture]
public class TesteExclusao : TesteBase
{
    private const int IdParaExcluir = 1;
    private ISession _session;

    [SetUp]
    public void Initialize()
    {
        Arrange();

        Act();
    }

    private void Arrange()
    {
        _session = Contexto.SessionFactory.OpenSession();
    }

    private void Act()
    {
        var produtoParaExcluir = _session.Get<Produto>(IdParaExcluir);
        using (var tran = _session.BeginTransaction())
        {
            _session.Delete(produtoParaExcluir);
            tran.Commit();
        }
    }

    [Test]
    public void NaoEstaNoBD()
    {
        _session.Clear();
        var produtoExcluido = _session.Get<Produto>(IdParaExcluir);
        Assert.IsNull(produtoExcluido);
    }
}

Neste eu excluo o Id igual a 1, e depois testo se o produto foi removido do banco, limpando a sessão para evitar cache, e fazendo novamente a consulta.

Posso rodar este teste quantas vezes quiser. Como ele continua funcionando?

Vocês já devem ter notado que os testes herdam de TesteBase. Vamos ver esta classe:

public abstract class TesteBase 
{
    [SetUp]
    public virtual void TestInitialize() 
    {
        OperacoesDeTestes.CarregarBancoDeDados(ConfiguracaoDeTestes.Esquema, ConfiguracaoDeTestes.DadosDeTeste);
    }
}

Notaram que ela faz uma carga do banco de dados, sempre antes de um teste rodar? É assim que garanto que o teste de exclusão nunca vai falhar por não encontrar produto para excluir, ou que o teste de inclusão vai falhar ao consultar e receber nulo.

Esta classe colabora com a classe OperacoesDeTestes. Esta classe, na prática, é só um wrapper em volta do NDbUnit. O NDbUnit é responsável por subir os dados no banco de dados, e ele também pode baixá-los. Ele faz isso com xml e xsd. Aqui vocês vêem os métodos desta classe:

public static class OperacoesDeTestes
{
    public static void CarregarBancoDeDados(
        string esquema,
        string dados)
    {
        var baseDeDados = ObterBaseDeDados();
        baseDeDados.ReadXmlSchema(esquema);
        baseDeDados.ReadXml(dados);
        baseDeDados.PerformDbOperation(DbOperationFlag.CleanInsertIdentity);
    }

    private static INDbUnitTest ObterBaseDeDados()
    {
        var baseDeDados = new SqlDbUnitTest(ConfiguracaoDeTestes.StringDeConexao);
        return baseDeDados;
    }

}

Notem que o método CarregarBancoDeDados lê o schema e o xml, e salva no banco, limpando os campos identity, se existirem, sempre usando o NDbUnit.

E de onde vem os dados? Há uma classe chamada ConfiguracaoDeTestes. Vejam ela:

public class ConfiguracaoDeTestes
{
    public static string DiretorioDeDados;
    public static string DadosDeBackup;
    public static string DadosDeTeste;
    public static string Esquema;
    public static string StringDeConexao;

    public static void InicializarVariaveisDeTeste(
        string basedir,
        string stringDeConexao)
    {
        StringDeConexao = stringDeConexao;
        DiretorioDeDados = Path.Combine(basedir, @"Dados\");
        DadosDeBackup = Path.Combine(DiretorioDeDados, "DadosBackup.xml");
        DadosDeTeste = Path.Combine(DiretorioDeDados, "Dados.xml");
        Esquema = Path.Combine(DiretorioDeDados, "Schema.xsd");
    }
}

Na prática ela somente segura valores de configuração, para que possam ser acessados facilmente de qualquer lugar. Entre os dados estão os diretórios onde guardamos os arquivos xml e xsd. Esta classe recebe seus valores de outra, chamada AssemblyInitialize.

Todo bom framework de testes permite fazer um setup inicial, que roda antes de todos os testes. O MbUnit não é diferente. Para permitir isso, basta usar o atributo AssemblyFixture sobre uma classe, e usar os métodos Setup e TearDown para preparar o ambiente de testes e desmontá-lo, respectivamente.

No meu caso, na inicialização do teste, preciso inicializar as variáveis de teste, que ficam na classe de configuração vista anteriormente, preciso configurar o NHibernate, e atualizar o esquema do banco de dados. Ufa, vamos ver como fica:

[AssemblyFixture]
public class AssemblyInitializer
{
    [SetUp]
    public static void AssemblyInitialize()
    {
        var baseDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
        ConfiguracaoDeTestes.InicializarVariaveisDeTeste(baseDir, StringDeConexao);
        ConfigurarNHibernateESubirEsquemaDoBancoDeDadosDeDominio();
    }

Aqui estamos declarando a classe e o método de inicialização. Estou obtendo o caminho do assembly em execução. É lá que fica meu xml e meu xsd. E passo isso, mais a string de conexão, para configurar o ambiente. Em seguida, configura o NH e subo o esquema do banco de dados.

Não vou entrar em detalhes de como o NH sobe o banco de dados, você pode ver a classe de configuração lá no BitBucket. Na prática a operação se chama schema update, onde ele compara o banco que está em produção com o que ele tem, e atualiza tudo.

Quero mostrar aqui a parte do NbUnit. Eu configuro ele com um xsd, criado a partir de um dataset tipado. Sim! Um dataset tipado. Eles ainda existem! Esse é o único lugar onde eu tenho usado datasets tipados nos últimos anos, e faz total sentido. Vejam ele, chamado de schema.xsd, aqui:

image

Notem três coisas. Primeiro: arranquei os table adapters, não precisamos dele, só queremos o xsd. Como queremos só o xsd, apaguei a custom tool, que fica na janela de propriedades. Sem custom tool, não há geração do arquivo que gera o dataset, isso elimina a criação do arquivo Schema.cs.

Isso me dá o schema que preciso para preparar o banco de dados. Basta então digitar o xml. O xml é muito simples:

<?xml version="1.0" encoding="utf-8" ?>
<Schema xmlns="http://tempuri.org/Schema.xsd">
  <Produto>
    <Id>1</Id>
    <Nome>meu nome</Nome>
  </Produto>
  <ProdutoId>
    <NextHi>1</NextHi>
  </ProdutoId>
</Schema>

Usando o namespace correto, ele funciona perfeitamente e o Visual Studio ainda valida o xml enquanto você escreve.

Basta então, apenas configurar estes dois arquivos para serem copiados para o diretório de testes.

image

Ao rodar o método OperacoesDeTestes.CarregarBancoDeDados, e passar este xml e xsd como parâmetros, tudo funciona. Os dados vão parar no banco de dados conforme o esperado.

E com isso fecho o ciclo completo: atualizo o schema do banco, subo os dados, e testo. A partir da criação desta pequena infra, é só escrever os testes livremente, sempre herdando de TesteBase.

O que acharam? Qual preferem, com infra Microsoft, ou infra (semi)open? Porque?


Postado na(s) categoria(s) Testes pelo Giovanni Bassi em 27 de agosto de 2010 às 02:48 | Tags: ,

TDC 2010 - Agile

Hoje (agora a pouco, na verdade) rolou minha palestra sobre Integração Continua na trilha de Agile do The Developers Conference 2010.

Subi a palestra para o SlideShare, como sempre. Está abaixo:


Postado na(s) categoria(s) Eventos pelo Giovanni Bassi em 22 de agosto de 2010 às 16:21 | Tags: , ,

The Developers Conference - Trilha .Net

No sábado palestrei com o André Dias no The Developers Conference 2010. Falamos sobre “tudo que você precisa saber sobre testes na plataforma Microsoft”. Na prática não falamos tudo, já que o Igor Abade palestrou na trilha de testes no dia anterior e mostrou toda a parte de testes manuais com Microsoft Test Manager (MTM). E também íamos falar milhões de coisas, só que dados os poucos 50 minutos de cada palestra, tivemos que reduzir para milhares. E como o tempo era pouco, resolvemos cortar qualquer coisa que tomasse tempo da palestra, isso incluiu os slides. Então, para essa palestra não tem slides. Fizemos palestra com o notepad, e íamos exibindo o conteúdo do notepad conforme a palestra adiantava. Vejam aqui o que foi o txt que usamos, pra ter uma ideia:

NO SLIDES !! YES DEMOS !!! 
================================================================
# TDC 2010
# Tudo o que você precisar saber sobre testes na Plataforma .NET
================================================================
André Dias
Consultor de ALM - Mic
rosoft | Visual Studio ALM Ranger | Scrum Developer Trainer
http://blogs.msdn.com/andredias
andre.dias@microsoft.com
@andrediasbr
===============================================================
Giovanni Bassi
Consultor Independente | MVP | Scrum Developer Trainer | Scrum Trainer
http://giovannibassi.com
http://unplugged.giggio.net
giggio@giggio.net
@giovannibassi

Agenda:
•	Testes unitários com Visual Studio / MSTest 
	o	Demos de unit tests
	o	Code Generation
	o	Teste de Tipos privados (PrivateObject, PrivateType)
	o	Code Coverage
	o	Teste de exceções
	o	Data-Driven Unit Test	
	o	Test Impact Analysis
	o	Suporte a TDD / Test First
	o	IntelliTrace
	
•	Outros frameworks/test runners
	o	NUnit
	o	MbUnit/Gallio
	o	TestDriven.Net
	o	NCover	

•	Coded UI Tests
	
•	BDD e TDD com Resharper + StoryQ

	
•	Conclusões

 

E isso foi o que ficou de fora, no final do txt. Se sobrasse tempo entraria:

•    O que eu preciso? (licenciamento)
    
•    Testes de banco de dados
    o    Teste unitário de stored procedures e funções
    o    Data Generation Plan
    
•    Mocks
    o    Moq
    
•    Testes de banco de dados com NDbUnit

•    Web Performance Test

•    Load Test        

•    Pex e Moles

Mas não sobrou tempo nenhum. Dá pra ver que tinha assunto pra mais uma palestra fácil, né?

A palestra foi super bem avaliada. Foi apresentação do assunto e demos e mais demos.

Agora fica o compromisso para eu e o André fazermos uma segunda pra concluir.


Postado na(s) categoria(s) Eventos pelo Giovanni Bassi em 22 de agosto de 2010 às 16:02 | Tags: ,

Teched Brasil

A Microsoft liberou as inscrições para os palestrantes, e já fui lá e me inscrevi.

Abaixo vocês vêem minha grade.

Alguns comentários:

  • Rob Ranches e Data Mining? Não dá pra perder. Aliás, Rob Ranches não dá pra perder nunca, só pelo show.
  • “Conheça os limites do Windows” é um nome muito legal pra uma palestra. Queria eu dar essa!
  • Vários amigos na lista. Sempre um prazer ver os MVPs, que encontro sempre, alguns futuros MVPs (evidentes na lista), e os amigos da Microsoft.
  • Minhas palestras estão destacadas em amarelo. Depois eu falo mais sobre elas.

Vejo vocês lá.

 

Programação do dia 13/09/2010

13:45 - 15:00

Título: ASP.NET MVC para desenvolvedores Web Forms 
Palestrante (s): Giovanni Bassi, Victor Cavalcante,
Sala: Cantareira 3
Público: Desenvolvedores / Profissionais de TI

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,
Sala: Jaçanã 1
Público: Desenvolvedores / Profissionais de TI

17:15 - 18:30

Título: Scrum Process Template para TFS 2010: Seja ágil de verdade! - 150 min 
Palestrante (s): André Dias, Giovanni Bassi,
Sala: Cantareira 5
Público: Desenvolvedores / Profissionais de TI

Programação do dia 14/09/2010

09:00 - 10:15

Título: Windows Server AppFabric Caching - construindo aplicações com alto desempenho na plataforma Microsoft 
Palestrante (s): Osvaldo Daibert,
Sala: Jaçanã 1
Público: Desenvolvedores / Profissionais de TI

10:45 - 12:00

Título: Teste de software com o Visual Studio 2010: Parte 2 de 2 
Palestrante (s): Brian Keller, Rodrigo de Carvalho,
Sala: Cantareira 4
Público: Desenvolvedores / Profissionais de TI

13:45 - 15:00

Título: ASP.NET MVC 2: O que há de Novo? 
Palestrante (s): Giovanni Bassi, Victor Cavalcante,
Sala: Cantareira 3
Público: Desenvolvedores / Profissionais de TI

15:30 - 16:45

Título: Implementando Serviços RESTful usando o Microsoft .NET Framework 
Palestrante (s): Israel Aece,
Sala: Cantareira 5
Público: Desenvolvedores / Profissionais de TI

17:15 - 18:30

Título: Conheça os limites do Windows 
Palestrante (s): Guilherme Carnevale,
Sala: Santana 2
Público: Desenvolvedores / Profissionais de TI

Programação do dia 15/09/2010

09:00 - 10:15

Título: PowerPivot Avançado: Modelagem, formulas e DAX 
Palestrante (s): Thiago Henrique Hernandes Zavaschi,
Sala: Cantareira 7
Público: Desenvolvedores / Profissionais de TI

10:45 - 12:00

Título: Criando Dashboards no PerformacePoint Services do SharePoint 2010 
Palestrante (s): Thiago Cruz Soares,
Sala: Cantareira 7
Público: Desenvolvedores / Profissionais de TI

13:45 - 15:00

Título: Criando Rich Internet Applications (RIA) com Silverlight 4 e WCF RIA Services 
Palestrante (s): Kelps Leite de Sousa,
Sala: Cantareira 3
Público: Desenvolvedores / Profissionais de TI

15:30 - 16:45

Título: Entendendo a Plataforma de Aplicações do Windows Phone 7 
Palestrante (s): Galileu Vieira, Luciano Condé,
Sala: Cantareira 5
Público: Desenvolvedores / Profissionais de TI

17:15 - 18:30

Título: Tudo o que você precisa saber sobre Data Mining 
Palestrante (s): Roberval Ranches,
Sala: Cantareira 7
Público: Desenvolvedores / Profissionais de TI


Postado na(s) categoria(s) Eventos pelo Giovanni Bassi em 19 de agosto de 2010 às 21:28 | Tags: ,

Não, AAA não é só uma pilha, é também uma forma de testar. O que eu vou mostrar aqui talvez você já conheça, talvez você já faça, mas talvez nunca tenha parado pra pensar no assunto.

  1. Todo teste passa por uma preparação, seja de ambiente, variáveis, banco de dados, etc. Essa preparação pode ser chamada em inglês de Arrange. Nosso primeiro A.
  2. Em seguida, todo teste passa por um momento onde estimulamos o sistema sendo testado (System Under Test em inglês, ou SUT). Isso é o Act, nosso segundo A.
  3. E logo em seguida, verificarmos se os resultados obtidos batem com os resultados esperados. Isso é o Assert, o terceiro A.

Essa não é a única forma de definir o ciclo de testes, há outras. Mas essa é uma das mais fáçeis de entender. Vamos pegar um teste comum, e vamos transformá-lo num testes triple-A. Vejam o teste abaixo, onde testo uma calculadora:

[TestClass]
public class TestaCalc
{
    [TestMethod]
    public void TesteSoma()
    {
        var calculadora = new Calculadora();
        var resultado = calculadora.Somar(2, 3);
        Assert.AreEqual(5, resultado);
    }
}

public class Calculadora
{
    public int Somar(int a, int b)
    {
        return a + b;
    }
}

Posso evidenciar os três As assim:

[TestClass]
public class TestaCalc
{
    [TestMethod]
    public void TesteSoma()
    {
        //arrange:
        var calculadora = new Calculadora();
        //act:
        var resultado = calculadora.Somar(2, 3);
        //assert:
        Assert.AreEqual(5, resultado);
    }
}

Mas isso não muda nada o que eu já estava fazendo.

Já ouviram falar que cada teste só pode testar uma coisa? Já tentou fazer isso? Já viu como é difícil se não pensarmos de forma estruturada? E o problema é mesmo a estrutura. Vou propor uma mudança estrutural.

Inicio separando a preparação (Arrange) e o estímulo (Act), das verificações (Asserts). Isso é fácil de fazer, a primeira ação é criar a ideia de contexto, que no teste anterior da calculadora não existia, e na prática, ficava encapsulado no método. O contexto vai ser aplicado à classe, e não mais ao método. O contexto do teste é a calculadora. O contexto é preparado e estimulado na inicialização do teste.

Toda classe fica com mais ou menos essa estrutura:

[TestClass]
public class Teste
{
    [TestInitialize]
    public void Inicializar()
    {
        Arrange();

        Act();
    }

    private void Arrange()
    {
        //prepara
    }

    private void Act()
    {
        //executa
    }

    [TestMethod]
    public void VerificaAlgo()
    {
        //faz as verificaoes
    }
    
    [TestMethod]
    public void VerificaAlgoAMais()
    {
        //faz outras verificaoes
    }
}

Para traduzir o teste de calculadora fica fácil. Coloco a criação da calculadora no arrange, a soma no Act, e as verificações no teste em si.

[TestClass]
public class DadaUmaCalculadoraQueSoma2Mais3
{
    private Calculadora _calculadora;
    private int _resultado;

    [TestInitialize]
    public void Inicializar()
    {
        Arrange();

        Act();
    }
    private void Arrange()
    {
        _calculadora = new Calculadora();
    }
    private void Act()
    {
        _resultado = _calculadora.Somar(2, 3);
    }
    [TestMethod]
    public void Totaliza5()
    {
        Assert.AreEqual(5, _resultado);
    }
}

Com isso, apenas separamos o teste em três métodos diferentes, e pode ser que não esteja valendo a pena.

A ideia começa a ficar mais interessantes quando o teste fica mais complexo. O teste passa a ser auto-explicativo, e as falhas passam a ficar mais evidentes. O exemplo a seguir deixa isso claro:

[TestClass]
public class TestaServicoEmissaoNFEmitindoNF
{
    private ServicoEmissaoNF _servico;
    private Pedido _pedido;
    private NotaFiscal _nf;
    private EnviadorDeMensagensFake _enviador;

    [TestInitialize]
    public void Inicializar()
    {
        Arrange();

        Act();
    }

    private void Arrange()
    {
        _pedido = new Pedido(500);
        _enviador = new EnviadorDeMensagensFake();
        _servico = new ServicoEmissaoNF(_enviador);
    }

    private void Act()
    {
        _nf = _servico.Emitir(_pedido);
    }

    [TestMethod]
    public void NFNaoÉNula()
    {
        Assert.IsNotNull(_nf);
    }
    
    [TestMethod]
    public void ValorDaNFÉIgualAoValorDoPedido()
    {
        Assert.AreEqual(_pedido.Valor, _nf.Valor);
    }

    [TestMethod]
    public void MensagemEhEnviada()
    {
        Assert.IsFalse(string.IsNullOrWhiteSpace(_enviador.MensagemEnviada));
    }
}

Nesse cenário, crio uma nota fiscal a partir de um pedido, e verifico 3 coisas: a NF é criada (não é nula), o valor da NF é igual ao valor do pedido, e uma mensagem é enviada durante o processo. Cada um é um único teste.

Poderia fazer isso sem o AAA explícito? Poderia. Ficaria assim:

[TestClass]
public class TestaServicoEmissaoNF
{
    [TestMethod]
    public void EmissaoDaNF()
    {
        //arrange
        var pedido = new Pedido(500);
        var enviador = new EnviadorDeMensagensFake();
        var servico = new ServicoEmissaoNF(enviador);
        //act
        var nf = servico.Emitir(pedido);
        //assert
        Assert.IsNotNull(nf);
        Assert.AreEqual(pedido.Valor, nf.Valor);
        Assert.IsFalse(string.IsNullOrWhiteSpace(enviador.MensagemEnviada));
    }
}

Porque eu não faria isso num cenário como esse?

  1. O teste testa 3 coisas diferentes;
  2. Se o primeiro assert falhar, eu não sei se os outros passaram;
  3. O método testa coisa demais, isso fica evidente pelo nome do método de teste

É uma troca de expressividade e manutenibilidade por velocidade na escrita do código. Como a diferença de velocidade é mínima, e a perda de expressividade é alta, eu decido por não fazer.

Isso fica ainda mais fácil se você criar uma classe abstrata para testes. Algo assim:

public abstract class TesteBase
{
    [TestInitialize]
    public void Inicializar()
    {
        Arrange();

        Act();
    }

    protected virtual void Arrange()
    {
    }

    protected abstract void Act();
}

Assim, o Arrange é opcional, o Act é obrigatório, e os testes você implementa como quiser.

Depois eu conto como melhorar isso ainda mais. Em breve. Estou devendo alguns posts…


Postado na(s) categoria(s) Testes pelo Giovanni Bassi em 18 de agosto de 2010 às 19:11 | Tags:

Dois webcasts serão apresentados pelo Richard Hundhausen, da Accentient, que criou junto com a Scrum.org o Professional Scrum Developer para .Net.

Serão em inglês, semana que vem:

Parte 1: Terça, 17/08, 15 hrs

https://www.clicktoattend.com/invitation.aspx?code=149942

Parte 2: Quinta, 19/08, 15 hrs

https://www.clicktoattend.com/invitation.aspx?code=149944


Postado na(s) categoria(s) Eventos , Scrum Developer , Scrum pelo Giovanni Bassi em 13 de agosto de 2010 às 18:19 | Tags: , ,

The Developers Conference 2010

Esse ano tem The Developers Conference (TDC), um grande evento da comunidade de desenvolvimento. E pela primeira vez o .Net fará parte do evento, que conta também com outras linguagens, como Ruby, Python e Java, além de trilhas tão diversas como Testes, noSQL e Arduino.

Estou organizando a trilha de .Net do TDC, e trabalhando junto com o Felipe Rodrigues na de Agile. O evento vai contar com 13 trilhas, 3 dias, e custará apenas 20 reais por trilha, ou seja, você vai gastar no máximo 60 reais, em um evento de 3 dias. Você faz a combinação que quiser.

Uma combinação interessante para desenvolvedores web: participar da trilha de SOA na sexta, .Net no sábado, que vai mostrar ASP.Net MVC 3, Silverlight 4 e outros, e web no domingo, que vai falar de SEO, HTML5, CSS3, etc.

Outra muito legal é igual a acima, mas em vez da de SOA, assistir a de testes na sexta, que também está bem legal.

E pros agilistas, vamos falar de Coaching, Integração contínua, clean code, entre outros. Uma combinação legal é ver .Net no sábado e Agile no domingo.

Pra quem curte uma piração e também gosta de hardware, a trilha de Arduíno, que acontece no domingo, é uma ótima pedida. Vai falar de Arduíno + injeção eletrônica, automação residencial, e até física quântica. Difícil é perder a trilha de agile que rola no mesmo dia.

Esperem ver vários MVPs, funcionários da Microsoft, e membros do .Net Architects por lá. Hélio de Sá, Fabio Galuppo, Tuca, Caverna, André Dias, Victor Cavalcante, são só alguns dos nomes que estarão por lá. Montei também um painel de linguagens do .Net, onde vamos falar de tudo, menos C# e VB. Inclua aí Boo, IronPython, IronRuby, F#, C++, e talvez outras.

Eu vou palestrar na trilha de .Net, na de Agile, e talvez na de testes, falando de integração contínua, testes, entre outras.

Em resumo, imperdível.


Postado na(s) categoria(s) Eventos pelo Giovanni Bassi em 9 de agosto de 2010 às 11:23 | Tags: , , , , , ,

No post em que diferenciei complicado, complexo e caótico eu explico alguns conceitos que deixam claro em quais tipos de projeto faz sentido uma abordagem ágil, e em quais faz sentido uma abordagem tradicional, baseada em cascata. Explico também o que significa ser simples, complicado, complexo, e caótico, além de explicar as características de um contexto complexo. Você vai aproveitar melhor este post se ler aquele primeiro.

Estou estudando o framework Cynefin e percebo que alguns conceitos complementam bem o que eu já havia iniciado, já que ele levanta os modelos de gestão apropriados a cada contexto.

A categorização é parecida com a que eu havia proposto antes, e que é parte do curso de Professional ScrumMaster:

Cynefin Framework

Nesse gráfico, temos expostos os contextos em que uma situação, um projeto de software, por exemplo, acontece. Estes contextos são classificados em ordenados e desordenados:

  1. Nos contextos ordenados as decisões são baseadas em fatos, existe uma clara relação de causa e efeito (causalidade), e o sistema restringe os agentes, ou seja, é possível limitar as ações e criatividade das pessoas e ainda assim obter resultados. Um estilo comando e controle pode funcionar, ainda que eu prefira uma liderança democrática, e não autocrática. Os contextos simples e complicados são contextos ordenados.
  2. Nos contextos desordenados há necessidade de avaliação empírica, e a análise de padrões é que determina a resposta. Há pouca ou nenhuma relação evidente entre causa e efeito (ainda que ela exista, é difícil de medir). Nesse cenário, somente o autogerenciamento e a autoorganização libertam os agentes para criar soluções que realmente endereçam os problemas que aparecem. Hierarquia estrutural e autocracia são o melhor caminho para o fracasso. Os contextos complexo e caótico são contextos desordenados.

O problema maior é tomar um pelo outro. A maioria dos líderes/gerentes imagina trabalhar em ambientes ordenados. Isso é um problema porque as respostas esperadas em cada contexto são diferentes. Ao tomar um pelo outro, as decisões ficam aquém do esperado e produzem desperdício, no mínimo.

No contexto simples e também no complicado, o ambiente é planejado e previsível.

No simples, sabe-se tudo ou quase tudo o que pode acontecer ao processo. Nesse contexto, os líderes sentem, categorizam e respondem, ou seja, eles avaliam a situação, as categorizam e decidem com base nos fatos categorizados. Nesse cenário, os líderes podem não perceber a mudança de contexto, de simples para complicado, complexo ou caótico, e caminham para a falha, já que o contexto mudou e eles continuam aplicando técnicas baseadas em sentir, categorizar e responder, na expectativa de uma previsibilidade que pode ser falsa, e achando que sabem mais do que sabem.

No ambiente complicado, muito pouco é desconhecido sobre o processo e o produto. Sabe-se mais do que não se sabe. Nesse contexto, os líderes sentem, analizam, e respondem, ou seja, é preciso analizar as situações que aparecem, e não só categorizá-las. Essa análise fica a cargo de experts, que precisam informar como responder. Nesse cenário, não os líderes (como no contexto simples), mas os experts é que correm o risco de não perceber a mudança de contexto, e, junto aos líderes, podem aplicar abordagens erradas para endereçar cada situação.

No contexto complexo, o desconhecido predomina sobre o conhecido, sabe-se pouco, e não se sabe o que não se sabe. É preciso levantar os fatos antes de tomar as decisões, e por isso, o processo não começa pelo sentir, como nos contextos ordenados, mas começa com sondar, e então sentir, e só então responder. É o processo empírico tateando a cada passo, porque sabe que não é possível crer no planejamento, já que não sabemos quase nada. Nesse cenário, tentar impor ordem e buscar previsibilidade é caminhar para o abísmo, já que o contexto é naturalmente desordenado; mais vale entender e abraçar a complexidade, adaptando-se sempre que necessário. Aqui o sistema restringe os agentes, devido à sua imprevisibilidade, e os agentes restringem o sistema, impedindo que ele caminhe para o total desconhecido, inspecionando frequentemente e adaptando sempre que necessário.

No contexto caótico, não só não sabemos nada, mas não conseguimos saber. Não adianta sondar, os resultados serão nulos ou inúteis. Causa e efeito não tem relação aparente alguma. Resta agir, e esse é o primeiro passo, seguido do sentir, e então responder. Os líderes agem, e então sondam os resultados, e respondem aos efeitos dessa sondagem, tentando trazer o contexto para algo no mínimo gerenciável, onde também não se sabe, mas pelo menos temos como tatear, ou seja, buscam o complexo. O ideal é atuar de forma rápida, a fim de reestabilizar; imagine um avião em queda, e girando – a primeira coisa que se faz é agir e fazer o avião parar de girar, só depois é que faz sentido buscar nivelar o avião. Buscar ler os instrumentos ou planejar seria absurdo. Neste contexto, o sistema e os agentes estão sem restrições, não há controle ou previsibilidade alguma, e não há como medir. Mas o caótico não é só ruim, ao mesmo tempo que busca agir, o líder tem em mãos uma grande oportunidade de mudança radical, proporcionada pela desordem absoluta e pela total falta de posição. Se o momento caótico passar e a mudança não acontecer, dificilmente ela acontecerá tão facilmente como poderia antes.

Reforçando: o grande erro está em liderar imaginando um contexto, quando na verdade estamos em outro. O mais comum é responder utilizando técnicas para contextos simples ou complicados, quando na verdade estamos no caótico ou complexo, por acaso os mais comuns no mundo de software.

Por exemplo, uma empresa que desenvolve software sob medida, sempre atuando em novos clientes, ambientes, tecnologias, e com pessoas diferentes, vive um ambiente no mínimo complexo e portanto pouco previsível. Aplicar técnicas baseadas em análise e resposta, como as baseadas no modelo cascata, ou atuar como um líder que comanda e controla, é ignorar o contexto em que o projeto vive, além de ignorar o que não se sabe. Pior, assumir que sabe, ou até basear-se em informações erradas, desatualizadas ou ambos.

O mesmo vale para o oposto. Uma empresa que trabalha com um software vanilla, que customiza para clientes sempre de forma semelhante, está sempre atuando no mesmo produto, ou seja, atua num ambiente provavelmente no máximo complicado. Nesse cenário, sondar é desnecessário, e trará um custo extra ao projeto. Basta analizar os resultados das medições e corrigir de acordo com o plano. Um modelo em cascata, baseado em alta previsibilidade, seria o ideal e o mais barato.

E você? Trabalha em qual contexto? As decisões dos líderes batem com o contexto?


Postado na(s) categoria(s) Agilidade , Gestão de projeto pelo Giovanni Bassi em 5 de agosto de 2010 às 14:52 | Tags: , ,

Sprocs???

Com razoável frequência alguém levanta a ideia de usar stored procedures (procs, para abreviar) porque melhora segurança e performance.

Como eu sei que isso não é verdade, e o assunto é levantado sempre, vou escrever esse post, depois é só linkar. Smile

Geralmente as consultas via procs são comparadas com queries feitas com texto SQL, que vou chamar de ad-hoc. Esse tipo de consulta é aquela onde você escreve “SELECT Id, Campo FROM Cliente WHERE Id = 1” e manda direto para o banco, e é também o usado por mapeadores objeto relacional (ORMs).

Vamos aos mitos:

  1. Stored Procedures permitem fazer cache do plano de execução, enquanto consultas ad-hoc não permitem
    Mito. Os planos de execução são armezanados para reutilização em procs e também em consultas ad-hoc. Vejam essa afirmação do MSDN:
    “In SQL Server 2000, whenever a statement within a batch causes recompilation, the whole batch, whether submitted through a stored procedure, trigger, ad-hoc batch, or prepared statement, is recompiled. In SQL Server 2005 and later, only the statement inside the batch that causes recompilation is recompiled.” Daqui.
    Esse outro artigo entra mais a fundo. Notem que o importante é o uso de parâmetros, não só para evitar o SQL Injection, mas também para permitir o cache do plano de execução (algo que o SQL Server 2008 já tenta resolver, mesmo se você não enviar o parâmetro).
  2. Stored Procedures estimulam reusabilidade.
    Mito. Reusabilidade pode ser atingida de diversas formas. Um modelo procedural, como o da programação de um banco de dados relacional, possibilita reusabilidade dentro deste paradigma. Eu prefiro estimular reusabilidade com OO, mas isso não quer dizer que não podemos reutilizar tanto em um quanto no outro.
  3. Stored Procedures ajudam a encapsular regras de negócio.
    Mito. Eu posso encapsular, com mais produtividade na programação, em um modelo OO.
  4. Stored Procedures são mais seguras. Com procs você pode remover os direitos a insert, update, delete e consulta, inclusive com granularidade na coluna de uma tabela.
    Mito. Ainda que seja possível fazer isso, se em uma operação de negócio o usuário precisa atualizar um campo, ele terá que ter acesso de atualização deste campo, se não direto, indiretamente pela proc. Isso fica ainda mais irrelevante quando vemos aquelas procs de CUD, ou seja, quando o programador cria 3 procs, uma para cada operação do CUD, e simplesmente pega os parâmetros e repassa para as declarações de insert, update e delete. A proc nesse caso é um mero proxy. A outra opção é colocar a regra de negócio no banco, algo absurdo na maioria dos cenários (não vou me aprofundar no porquê, vai ficar para outro post).
  5. Stored Procedures diminuem o consumo de banda, já que a consulta que vai ao banco é somente o nome da proc e seus parâmetros.
    Meia verdade. De fato a operação que vai ao banco é menor. Mas em uma operação de consulta, o maior peso está no retorno da consulta, cheio de dados, e não na solicitação, que é um texto curto. A diferença entre a consulta com proc e sem chega a ser ridícula. E em uma operação de atualização do banco, os dados que vão subir tem que ser enviados da mesma forma, e o resto da declaração de uma operação ad-hoc é só um pouco maior se comparado com a proc. Além disso, nas redes de hoje, com servidores web ao lado de servidores de banco em rede gigabit, o gargalo não fica na rede.

Além destes mitos, o que mais me incomoda é que procs praticamente impedem o uso de ORMs. E ORMs são praticamente obrigatórios em um projeto que quer ter um mínimo de produtividade. Escrever SQL na mão hoje em dia é algo absolutamente desnecessário para 90% das aplicações, e nos 10% que sobram, só um pequeno percentual teria algum ganho sobre o uso de SQL manual sobre um ORM. Mas isso fica para outro post também.

Um caso onde vejo uso de procs como útil: ETL (veja update 1 abaixo). Geralmente é muito difícil fazer carga de grandes massas de dados via interação com o client, seja ele .Net, Java, C++, VB6, ou o que for. O ideal é a carga acontecer no banco, e aí procs vão bem. O maior problema, derivado do ETL, é a duplicação de regras de negócio, já que uma operação de negócio que entra via carga externa estará sujeita às mesmas regras de uma entrada manual, normalmente também permitida. É algo que aumenta o custo de manutenção, mas muitas vezes não tem jeito.

É isso. Joguem as procs no lixo, programem com ORMs (ou bancos NOSQL), e sejam produtivos.

Update 1: O Gustavo Maia Aguiar, MVP de SQL, levanta que procs não são boas para ETL, e expõe vários motivos. Vejam  nos comentários.

Update 2: O Luciano Moreira (Luti), também MVP de SQL, também responde a este post, mas com outro post. Imperdível se você gostou da discussão.


Postado na(s) categoria(s) Polêmicas pelo Giovanni Bassi em 22 de julho de 2010 às 16:16 | Tags:

(Update: Veja também o artigo irmão deste: Testando o banco de dados: com infra não Microsoft)

Eu testo minhas aplicações, e algo que não pode ficar de fora é o teste do banco de dados. Vocês sabem que eu não gosto de colocar regras de negócio no banco de dados (e isso é assunto para outra discussão), então para mim, testar o banco de dados é testar a interação da aplicação com o banco de dados. E eu uso ORMs, ou seja, na verdade, o que eu preciso testar é a se o meu mapeamento está funcionando e se o schema do banco está correto, de acordo com o que a aplicação espera.

Neste post eu vou mostrar como fazer isso com infra Microsoft, ou seja, com Data Dude (VS Database) e Entity Framework. No próximo vou mostrar com alguns componentes open source. O próximo vem semana que vem.

Você só precisa de um Visual Studio 2010 Premium, porque na edição professional não vem o Data Dude, que é o antigo VS Database edition, que não existe mais. Ele tem um projeto de banco de dados, e vou usá-lo.

Mas antes de mais nada…

Como testar algo que interage com o banco de dados? É óbvio que se interage com o BD, não pode ser um teste unitário, tem que ser um teste integrado, nesse caso, integrado com o banco. O que testar?

Os testes vão manipular o banco, vão incluir, alterar, excluir, e consultar, ou seja, vão fazer operações CRUD. Quando um teste altera os dados do banco pode ser que ele altere o resultado de outro teste. Por exemplo, em um teste eu incluo um item em uma nota fiscal e salvo, antes ela tinha 10, agora tem 11. Em outro teste eu consulto a mesma nota, e verifico se ela tem 10 itens, o teste falha, porque o teste que inseriu o teste rodou antes. Eu até poderia determinar a ordem dos testes, mas isso deixaria meu plano de testes confuso e ruim: jamais poderia rodar um único teste sem antes rodar os outros. Testes devem rodar sempre independentes uns dos outros. Como resolver? A cada teste o banco deve ter seus dados reiniciados. Como subir estes dados? Já vi pessoas usarem transações, e dar rollback no final, mas isso é no mínimo incompleto: quem sobe os dados iniciais? É feito na mão? Além disso, o esquema tem que estar atualizado. Não dá pra testar se falta uma tabela, uma coluna, ou se há alguma diferença. Nossa infra de testes deve resolver esse problema.

Primeiro vamos resolver o problema do esquema. O Data Dude tem um projeto de banco de dados. Vejam lá, File > New > Project > Database > SQL Server > SQL Server 2008 Database Project (clique nas imagens para ampliar):

image

Esse projeto cria todo o esquema que você vai precisar e também os dados. Não vou explicar aqui o que é o Data Dude, mas confie em mim, funciona e é muito legal. Para mais informações, baixe o training kit, baixe a VM, e/ou veja online a documentação.

Criei também um projeto class library e fiz um mapeamento simples no EF, vejam só:

image

Esse mapeamento já gerou a classe de produto e também o contexto que eu quero testar.

Gerei o SQL, importei ele pro projeto de database:

image

E tenho o schema lá:

image

Eu quero ter uma carga de dados, então criei um plano de geração de dados, ou data generation plan:

image

Ele gera dados para minhas tabelas, vou precisar disso mais pra frente.

Criei um projeto de testes, e pra ganhar tempo, pedi pra criar um teste de banco de dados, que vai me ajudar na criação da infra de testes com banco:

image

Ele me dá a opção de gerar meu banco (fecha azul), e incluir o meu plano de geração de dados (flecha vermelha).

image

Ao fazer isso, vários artefatos interessantes apareceram no meu projeto. Vamos vê-los. Primeiro meu web.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="DatabaseUnitTesting" type="Microsoft.Data.Schema.UnitTesting.Configuration.DatabaseUnitTestingSection, Microsoft.Data.Schema.UnitTesting, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </configSections>
    <DatabaseUnitTesting>
        <DatabaseDeployment DatabaseProjectFileName="..\..\..\Database1\Database1.dbproj"
            Configuration="Debug" />
        <DataGeneration DataGenerationFileName="..\..\..\Database1\Data Generation Plans\DataGenerationPlan1.dgen"
            ClearDatabase="true" />
        <ExecutionContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.\sqlexpress;Initial Catalog=TesteIntegradoBanco;Integrated Security=True;Pooling=False"
            CommandTimeout="30" />
        <PrivilegedContext Provider="System.Data.SqlClient" ConnectionString="Data Source=.\sqlexpress;Initial Catalog=TesteIntegradoBanco;Integrated Security=True;Pooling=False"
            CommandTimeout="30" />
    </DatabaseUnitTesting>
</configuration>

O Web.config está com toda a configuração para gerar o banco e fazer o deploy dos dados, inclusive o ponteiro para o data generation plan.

Foi criada também esta classe:

[TestClass]
public class DatabaseSetup
{
    [AssemblyInitialize]
    public static void InitializeAssembly(TestContext ctx)
    {
        DatabaseTestClass.TestService.DeployDatabaseProject();
        DatabaseTestClass.TestService.GenerateData();
    }

}

Notem o atributo AssemblyInitialize. Ele indica que quando antes deste assembly de teste rodar, este método será executado. Ele fará duas coisas: subirá o schema do banco de dados (método DeployDatabaseProject) e gerará os dados (método GenerateData). Esse segunda chamada de método não vai ficar aí, mas por enquanto tudo bem.

Agora eu posso excluir o teste de banco de dados que foi criado, ele servia pra criar os artefatos.

Agora só falta criar o teste que testa a interação com o banco em si. Vamos adicionar a classe de testes, usando o novo basic test, que vem sem aquele monte de linhas que eu sempre apago:

image

Ela fica assim:

[TestClass]
public class TesteInclusao
{
    private Produto _produtoParaIncluir;
    private Model1Container _container;

    [TestInitialize]
    public void Initialize()
    {
        Arrange();

        Act();
    }

    private void Arrange()
    {
        _container = new Model1Container();
        _produtoParaIncluir = new Produto
                       {
                           Nome = "um"
                       };
    }
    
    private void Act()
    {
        _container.AddToProdutoes(_produtoParaIncluir);
        _container.SaveChanges();
    }
   
    [TestMethod]
    public void NaoEhIgualAZero()
    {
        Assert.AreNotEqual(0, _produtoParaIncluir.Id);
    }

    [TestMethod]
    public void EstaNoBD()
    {
        var outroContainer = new Model1Container();
        var produtoIncluido = outroContainer.Produtoes.Single(p => p.Id == _produtoParaIncluir.Id);
        Assert.AreEqual("um", produtoIncluido.Nome);
    }
}

Notem que estou testando diretamente o container do Entity Framework.

O teste deve passar. Não esqueça de puxar as strings de conexão do projeto de class library para o projeto de testes, senão o container não vai ser criado. O banco subiu, o dado foi inserido. Você pode realizar uma consulta manual e confirmar, se você não acreditar no seu teste.

E um teste para excluir? Será que fuciona? Vamos olhar os dados gerados no plano de geração de dados:

image

Posso pedir para consultar por id, ou por nome, e então excluir. Vou pedir por id, que é gerado automaticamente por identity no SQL Server. Vejam o teste:

 

[TestClass]
public class TesteExclusao
{
    private const int IdParaExcluir = 1;
    private Model1Container _container;

    [TestInitialize]
    public void Initialize()
    {
        Arrange();

        Act();
    }

    private void Arrange()
    {
        _container = new Model1Container();
    }
    
    private void Act()
    {
        var produtoParaExcluir = _container.Produtoes.Single(p => p.Id == IdParaExcluir);
        _container.DeleteObject(produtoParaExcluir);
        _container.SaveChanges();
    }
   
    [TestMethod]
    public void NaoEstaNoBD()
    {
        var outroContainer = new Model1Container();
        var produtoExcluido = outroContainer.Produtoes.SingleOrDefault(p => p.Id == IdParaExcluir);
        Assert.IsNull(produtoExcluido);
    }
}

E funciona!


Se em outro teste eu quiser consultar o id 1, eu poderia ter problemas, já que o teste de exclusão poderia interferir. Para resolver isso eu puxo para o teste de consulta o setup dos dados no banco, veja a chamada de GenerateData, destacada.

 

[TestClass]
public class TesteConsulta
{
    private const int IdParaConsultar = 1;
    private Model1Container _container;
    private Produto _produtoEncontrado;

    [TestInitialize]
    public void Initialize()
    {
        Arrange();

        Act();
    }

    private void Arrange()
    {
        _container = new Model1Container();
        DatabaseTestClass.TestService.GenerateData();
    }
    
    private void Act()
    {
        _produtoEncontrado = _container.Produtoes.SingleOrDefault(p => p.Id == IdParaConsultar);
    }
   
    [TestMethod]
    public void ExisteNoBD()
    {
        Assert.IsNotNull(_produtoEncontrado);
    }
    [TestMethod]
    public void TemNomeCorreto()
    {
        Assert.AreEqual("aquele dado gigante gerado", _produtoEncontrado.Nome);
    }
}

Isso garante a consistência dos dados entre os testes.

 

Com isso posso criar testes à vontade, o banco sempre vai ter o último esquema e dados atualizado. Não preciso me preocupar com os dados, eles sempre vão estar lá. Isso é o básico dos testes integrado com banco de dados. O Visual Studio permite toda essa integração de maneira simples. Esse tipo de cenário fica especialmente importante quando não usamos ORMs, já que todo o acesso a dados é manual, e nesse caso testamos nossos DAOs, e também quando usamos POCO, onde o mapeamento é mais manual do que o que usei aqui.

No próximo vou mostrar como resolver isso sem o Data Dude, já que ele está limitado ao SQL Server e aos poucos providers extras que foram feitos até agora. E sem Entity Framework também.


Postado na(s) categoria(s) Team System , Testes pelo Giovanni Bassi em 19 de julho de 2010 às 19:02 | Tags: ,

Eu vou no TechEd Brasil 2010. Você vai?Sim, os motores estão começando a esquentar: o Tech·Ed Brasil 2010 está chegando. Milhares de pessoas estarão presentes no maior evento da comunidade Microsoft brasileira.  O Tech·Ed  é promovido pela Microsoft, e com conteúdo entregue por MVPs, funcionários Microsoft, e membros influentes da comunidade, ou seja, só gente que sabe muito sobre tecnologia em geral, e mais ainda sobre o tema que estará palestrando.

Esse ano o evento será em Setembro, de 13 a 15, no Expo Center Norte, em São Paulo. É um lugar grande, que é capaz de receber muita gente confortavelmente. Pra quem é de fora de São Paulo, tem um motivo a mais para vir: o QCon São Paulo acontece exatamente antes, dias 11 e 12 de Setembro, sábado e domingo. O Tech-ed começa na segunda.

Eu sou presença assídua no TechEd a anos, praticamente desde que o evento iniciou no Brasil. É imperdível, é sem dúvida o melhor evento do ano no país para absorver conteúdo técnico. Além disso, todo mundo sabe, Tech Ed não é só estudo, é também networking e diversão. Ano passado nos divertimos muito reencontrando amigos da comunidade que são de fora de São Paulo, tanto durante o evento em si, quanto depois, nos happy hours, jantares e baladas que acompanham obrigatoriamente qualquer evento de peso. Metade do evento são esses encontros e a experiência de estar presente. Só a outra metade é o conteúdo. E um não vive sem o outro.

O conteúdo do evento está ótimo: basta olhar as tracks, lotadas de assuntos instigantes: computação na nuvem, desenvolvimento web, ferramentas, linguagens e frameworks de desenvolvimento, e, vejam só: práticas de desenvolvimento. Sim, no TechEd se fala bastante de práticas, basta dar uma olhada nas palestras sobre práticas do TechEd americano deste ano pra ter um gostinho. Se o nosso tiver metade destas palestras já está ótimo.

Pra ter uma ideia de como foi o TechEd nos anos passados, basta dar uma olhada nos posts anteriores deste blog, na tag “teched”. Está lotado de fotos e comentários, e tem até um post onde cataloguei o twitter, sempre usando a hashtag #TechEdBrasil (esse ano mudou, estamos usando a hashtag #TechEdBR). O primeiro relato é de 2008, já que o blog só nasceu neste ano, e dá pra ver que eu estava começando a falar com a comunidade para criar o .Net Architects. Sim, o TechEd de 2008 ajudou a fazer o grupo acontecer, foi lá que eu conheci o Victor Cavalcante e o Valdir Rogerio, que na época trabalhavam na Unip, e apoiaram a ideia de fazer as reuniões do grupo por lá, onde elas são até hoje. TechEd não é só conteúdo, diversão e networking, também é comunidade!

 

Foi no TechEd que conheci muita gente da comunidade técnica. Não é toda hora que você tem a oportunidade de ver juntas dezenas de pessoas que conhecem tão a fundo cada assunto.

Vi algumas críticas com relação ao valor do evento, que está agora por 900 reais (vai aumentar mais ou menos uma vez por mês, o preço inicial era 800 reais). Mas dada a qualidade do evento e do conteúdo, eu acho que é um preço justo. Lá fora o TechEd bate quase 4 mil reais, e sempre lota com milhares e milhares de pessoas. Se pesar pra você, faça como eu sempre fiz: peça para seu empregador pagar. Eu acho que nunca paguei um TechEd, porque eu ia atrás dos executivos da empresa para bancarem o evento, eu justificava que era importante, que ia dar retorno. Quando me tornei independente comecei a palestrar no evento, não preciso mais pagar. Mas não teria problemas em pagar, aliás, pagaria até mais. Acredito que vale cada centavo.

Pra ajudar a promover o evento montei alguns badges. Pegue o que fizer mais sentido pra você e coloque onde achar melhor (site, blog, email). Não esqueçam de linkar para www.teched.com.br (vejam exemplo aí do lado direito, em “Selos”). As imagens estão abaixo (clique para link para imagem ampliada):

EuVou-P

EuVou-P

EuVou-P

Mais informações para ficar atento ao evento, e se preparar:

  1. O Fabio Hara está no comitê do evento, e está falando toda hora sobre ele. E também no twitter.
  2. Também da comissão, o João Paulo (aka JP) também pode soltar alguma coisa no seu blog. Mas ele está falando sobre o assunto mesmo é no Twitter.
  3. O Thiago Everton montou um guia para quem vai pela primeira vez.
  4. No Twitter, a hashtag #TechEdBR já está bombando, e a conta oficial é a @TechEdBrasil.
  5. Fique atento aos MVPs brasileiros, sempre sai alguma coisa lá. O Rodolfo Roim, que é MVP Lead também é capaz de soltar alguma informação por lá, senão antes, talvez depois do evento.
  6. Fique atento à página de palestrantes, que acredito que vai ser atualizada em breve. Os palestrantes, assim que puderem contar que foram convocados para palestrar vão começar a falar sobre o assunto.

Para aproveitar melhor, algumas dicas:

  1. Essa é óbvia: vá ao evento. Por mais que algumas palestras depois vão parar em webcasts, ou até que você possa baixá-las online do site americano ou coisa do tipo, nada substitui a experiência ao vivo.
  2. Fale com as pessoas. Não tenha receio de entrar em uma roda de pessoas desconhecidas, principalmente se forem funcionários Microsoft ou MVPs. Chegue junto, se apresente, tire dúvidas, troque cartão de visita, conte experiências. Uns anos atrás, antes de eu ser nomeado, me parecia que alguns MVPs davam a impressão que não queriam falar com a comunidade. Era impressão errada minha: todos gostam de uma boa conversa. Se a pessoa não puder falar porque tem algum compromisso ou algo do tipo, ela vai te dizer.
  3. Durma antes do evento. Pra aguentar o ritmo intenso da semana. Esse vale mais ainda se você for ao QCon.
  4. Agende-se para dormir menos durante os dias do evento. À noite sempre tem happy hour, balada, jantares, alguma coisa. O Twitter avisa, e as pessoas no próprio evento se comunicam. Só como exemplo: No AgileBrazil saimos praticamente todas as noites, no TechEd de 2009 também.
  5. Assista as palestras mais importantes, mas você não precisa assistir todas. Às vezes um bate papo com um palestrante no corredor vale 10 vezes mais que uma palestra.
  6. Assista aos keynotes. Eles dão o tom do resto do evento.
  7. Vá ao ask the experts. É lá que a comunidade pode realmente se conhecer e tirar suas dúvidas com os caras que mais manjam de cada assunto no país.

É isso aí. Vejo vocês lá.


Postado na(s) categoria(s) Eventos pelo Giovanni Bassi em 3 de julho de 2010 às 02:05 | Tags: ,

Não estou entendendo nada!!!

Cliente presente é algo que todos entendemos que é obrigatório para entregar um projeto com sucesso. Será que é suficiente?

Tenho visto alguma frequência que desenvolvedores se esforçam para construir uma aplicação corretamente, buscam um modelo rico, OO, fugindo do modelo anêmico. Usam tecnologias de ponta, ORMs, bancos NOSQL. Tem cliente presente. Entregam em iterações curtas, e chegam até a buscar o release contínuo. Buscam evitar o Scrum flácido, praticam XP, programam pareados. E falham. Quero analisar aqui um dos motivos que tenho visto para essa falha.

É comum que o cliente, apesar de presente, não tenha todo o entendimento de como o software deve se comportar. Um Product Owner pode saber o que deve ser feito, mas frequentemente não sabe como a aplicação deve funcionar em detalhes. Mas tudo bem, ele sabe quem sabe. E quem sabe é o especialista de negócio, ou business expert. Essa é a pessoa que realmente realiza as ações de negócio hoje, provavelmente de forma manual no Excel, como boa parte do planeta. É ele que sabe como as coisas devem funcionar, em detalhes.

Só que entender o negócio é algo complicado, e hoje em dia, mais do que nunca, precisamos de especialistas. E quem faz o trabalho super especializado de entender o negócio? O analista de negócio, é claro; vou chamá-lo de André. Ok, temos times multidisciplinares, pessoas multidisciplinares. Isso significa que provavelmente temos mais de uma pessoa no time que sabe fazer análise, mas ninguém o faz tão bem quanto o André. O André se especializou, ele leu o BABOK todo, fez cursos e mais cursos de análise, entende bem de usabilidade, conhece diversas técnicas para entender o que o especialista de negócio precisa, e sabe como documentar isso, como passar esse conhecimento pra frente.

Mas ele não programa.

Quer dizer, ele está num time multidisciplinar, mas ele prefere não programar. Quando está na hora de ele ser multidisciplinar ele escreve uns casos de testes, e está aprendendo a especificar com testes de aceitação com os Test Cases do Visual Studio, ou Fitnesse, ou Cucumber. Já faz uns 5 anos ou mais que o André prefere não programar. E ele é feliz assim, ele gosta de investir seu tempo no desenvolvimento de suas soft skills, é o que ele mais gosta de fazer. Isso é normal, todo mundo tem suas preferências, e estas habilidades são úteis ao projeto.

Então ele vai lá, analisa o negócio. Prepara o conhecimento e o transfere da melhor forma possível para o codificador – vou chamá-lo de Carlos – que vai implementar com código o que André analisou. O Carlos não fala com o especialista de negócio, ele fala com o André.

O André fala com o especialista de negócio sobre o negócio. Se o domínio é um caixa eletrônico, ele fala em saques, depósitos, saldos.

O André também fala com o Carlos. Ele fala de regras de negócio, fluxos principais, fluxos alternativos, wireframes, critérios de aceitação e até de tabelas de banco de dados de vez em quando. E no meio desse monte de outras coisas, ele também fala de saques, depósitos e saldos.

O Carlos, quando tem uma dúvida, pergunta pro André, que pergunta pro especialista de negócio. O especialista responde pro André, o André responde pro Carlos. O Carlos daí conta pros outros codificadores, analistas de banco de dados, etc. Ou o André conta.

Não preciso dizer que isso é um telefone sem fio, não é? Quem já brincou de telefone sem fio sabe que o que sai de um lado dificilmente é igual ao que chega do outro lado. E é assim que tantos consultores, cursos, etc, recomendam que façamos análise de negócio. Com telefone sem fio. Esse é um dos grandes motivos para a falha na entrega: entendemos errado porque o processo de comunicação é falho.

O Carlos, ao contrário do André, não se aprofundou em análise de negócio. Pode ser que ele odeie analisar o negócio, pode ser que não, mas de qualquer forma ele não desenvolveu tanto suas soft skills. Ele prefere codificar, ele se aprofundou em padrões de projeto, em OO, em assuntos diferentes do que o André se aprofundou.

Como resolver isso? Eliminando o analista de negócio do projeto? Claro que não! Quem fará a análise, o Carlos, que não é tão especializado? Não, é o próprio analista que fará a análise do negócio, mas ele o fará de uma maneira um pouco diferente. Em vez de fazer a ponta entre especialista de negócio e codificador, ele vai trabalhar como um facilitador da comunicação dos dois. Ele vai trazer o codificador ao especialista de negócio, ou vice-versa, e usar suas técnicas e soft skills para levantar as informações mais relevantes, na maior quantidade possível. Os três, juntos, vão desenhar a aplicação.

E na hora de parear, porque não o André, sentado ao lado do Carlos, enquanto ele codifica? Isso sim, é trabalhar num time verdadeiramente multidisciplinar.

Ingrediente pro sucesso.


Postado na(s) categoria(s) Gestão de projeto pelo Giovanni Bassi em 1 de julho de 2010 às 01:26 | Tags: ,

logo-trans Ok, eu ia reportar o evento ao vivo… mas eu também ia dormir 8 horas por dia. Nenhum dos dois aconteceu. Então o relatório do evento segue agora, alguns dias atrasado, mas nem por isso tão desatualizado.

O evento foi muito bom. Já vi diversos relatos em blogs de amigos e de desconhecidos agora, depois que o evento já aconteceu, e só sucessos. Algumas críticas vieram, mas nada demais, só recomendações para deixar o de 2011 ainda melhor. Trabalhamos intensamente no evento vários meses, e o sucesso é a concretização deste trabalho.

O evento abriu com dois dias de cursos, sendo um de XP, onde fui um dos instrutores, um de CSM, um de CSPO, e outro de coaching. Não estive presente nos outros 3 cursos, mas pelo feedback que recebi também foram muito bons. No de XP tivemos nada menos do que seis instrutores (contando comigo) com vasta experiência e conhecimento. Passamos por toda a teoria, e ainda tivemos exercícios práticos e muitas dúvidas resolvidas. Dava pra ter feito 2 dias de curso tranquilamente, e aprofundado mais em alguns assuntos. Na verdade, dava pra fazer 1 semana numa boa, de tanto conteúdo que nós 6 tinhamos pra falar. Considerando que os 6 eram também palestrantes do evento e membros da organização, ou seja, todos adoram falar, nos saímos muito bem, e a dinâmica do curso foi ótima. Com os três cursos somamos mais de cem pessoas.

Algumas fotos (clique para ampliar):

Dúvidas dos alunos para resolver e horário:

Coffee-break:

Times praticando:

Pareando a três:

Parte da turma:

Curso de CSM:

Curso de CSPO:

À noite saímos pra jantar, foi muito legal. Aqui vocês vêem parte dos instrutores e comissão do evento:

No segundo dia do evento, outro jantar, dessa vez bem mais cheio. Muita gente já tinha chegado para participar do evento. A mesa deve ter batido quase 100 pessoas:

Em Porto Alegre é comum esse licor, servido em cascata. Novamente tomamos neste restaurante. Quem foi que disse que agilista não gosta de cascata?

No terceiro dia do evento abrimos com as palestras, onde quase 900 pessoas participaram. A abertura foi feita pelo Martin Fowler, e foi como a apresentação de um Rock Star. O Fowler é engraçado, ele ficou disponível o evento todo no estande da Thoughtworks, empresa que trabalha que também patrocionou o evento e estava lá, mas não tirava foto com ninguém porque dizia que ia parecer um político. Eu já tinha ouvido essas histórias, é engraçado ver que as idiossincrasias afetam todos. A palestra foi ótima, foi na verdade 3 palestras em 1, onde ele abordou, entre outros assuntos, o Scrum Flácido e o débito técnico. Isso foi muito legal, porque foi o Scrum flácido que inspirou a criação do programa Professional Scrum Developer da Scrum.org. Várias outras palestras no evento se relacionaram com a do Fowler, o que foi ótimo.

Fowler palestrando:

Auditório lotado:

Um telão reportou o evento ao vivo no twitter:

Isso foi ótimo porque dava pra ver na hora o que o pessoal estava pensando, além de estimular o pessoal a dar feedback.

Esta é a área onde ficavam os patrocinadores, aqui vocês me vêem ao lado da grade:

Aqui uma visão melhor, em um momento em que não estava tão cheio:

O evento seguiu o resto do dia com break-out sessions, e bastante movimento no open space, com diversas discussões:

Tivemos um workshop com o Philippe Kruchten de Release Planning Game, onde de Mariana Bravo, Samuel Crescêncio, Teresa Maciel e eu servimos de facilitadores, ao lado do Philippe:

Achei o workshop muito legal, principalmente para quem está começando. É um jogo, onde as pessoas conseguem ter uma visão clara sobre débito técnico, planejamento iterativo, entre outros conceitos.

A Microsoft palestrou também. O Igor Abade foi o responsável por mostrar que a Microsoft está abraçando a ideia de apoiar processo ágeis. O Igor parecia apreensivo com a palestra, mas foi muito bem recebido e a sala estava bem cheia, ainda mais se considerar que palestras de patrocinador não costumam ter muita gente:

Eu estava particularmente podre. Como fazia parte da organização estava dormindo muito pouco, e eu já vinha de uma semana fora de casa, ministrando o Professional Scrum Developer em BH, e também dormindo pouco por lá. Na quinta atingi meu limite, estava exausto e com dor de cabeça. E no fim do dia tinha minha palestra. A adrenalina da palestra me reanimou, e apresentei a palestra com toda a energia:

Mas depois eu quase desmaiei.

Mentira, depois fomos para o John Bull, um bar de Porto Alegre onde estava rolando um Rock, para a festa do evento. Mas não consegui acompanhar o resto do pessoal, que esticou madrugada adentro. Eu estava quase morto, voltei pro hotel para descansar. Descansei tanto que perdi o keynote do Philippe Kruchten, cheguei lá para o jogo do Brasil, que todos já sabem, era melhor não ter assistido. Perdemos um slot de palestra, mas imaginem se o Brasil tivesse ido bem? Seríamos crucificados por termos ignorado o jogo. Fazer o que?

A sexta seguiu com mais palestras e no final um keynote que foi um fechamento excepcional! O Klaus Wuestefeld, um dos pioreiros da agilidade no país apresentou sua visão sobre o futuro do XP, onde ele praticamente desconstruiu o XP todo, e criou o Klaus Process, o KP, onde somente dois valores importam: Learning e Coolness. Fui uma palestra muito boa, e serviu para dar uma ótima visão sobre para onde estamos indo. Pode ser que não seja exatamente onde o Klaus espera que seja, mas ele ajudou a abrir os horizontes:

 

Na sexta tivemos um jantar da organização e alguns amigos, que eu não fotografei porque merecia descansar da câmera um pouco. Depois publico as outras fotos.

Gostei do evento e provavelmente estarei na organização da edição do ano que vem. Vamos ver. Foi ótimo dar rostos aos membros da organização, já que eu só conhecia pessoalmente um ou outro. Aproximar-me de pessoas como o Samuel Crescêncio, Rodrigo de Toledo, Paulo Caroli, entre outros, é algo sem preço.

Aqui o time todo da organização reunida para foto histórica:

Acreditem se quiserem, nossa primeira reunião presencial se deu na segunda-feira, um dia antes do evento. Toda a coordenação foi remota. Quem disse que times ágeis obrigatoriamente tem que estar colocados?

Valeu pessoal!


Postado na(s) categoria(s) Agilidade , Eventos pelo Giovanni Bassi em 29 de junho de 2010 às 02:09 | Tags: ,

ndc2010

A Conferência Norueguesa de Desenvolvedores de 2010 (NDC – Norwigean Developers Conference) postou novamente (assim como no ano passado) todos os videos para download. E as palestras foram incríveis. Não dá pra não ver.

A conferência é anual, caríssima, e focada em .Net e Agile.

Vão lá baixar e divirtam-se.


Postado na(s) categoria(s) Agilidade , .Net , Eventos pelo Giovanni Bassi em 28 de junho de 2010 às 02:48 | Tags: ,

QCon SP Fechei com o pessoal da InfoQ minha participação no QCon São Paulo 2010. O evento vai ser nos dias 11 e 12 de Setembro, sábado e domingo, logo antes do TechEd Brasil (que começa dia 13, segunda-feira, e vai até a quarta-feira, dia 15 de Setembro).

No QCon vou valar de BDD, com minha palestra intitulada “Behavior-Driven Development (BDD) no mundo real”. Vejam o resumo:

BDD é um assunto controverso, muitos não entendem o que ele significa, e não sabem como usar. O que é (e de acordo com quem)? É igual TDD, é diferente, é melhor, é pior? Precisamos de ferramentas? Quais as opções disponíveis? Vale a pena? O que as pessoas que trabalham com BDD querem dizer quando falam em "especificações executáveis"? O que funciona e o que o levou a falhar?
Nesta palestra abordaremos essas perguntas, e avaliaremos algumas técnicas e ferramentas que você pode usar para começar a desenvolver software com BDD para aplicações do mundo real. Mais do que uma excelente técnica para criar e organizar testes unitários, BDD é também uma ótima maneira de se comunicar com os usuários.

Interessante, não?

Estou na track de Agile, no sábado, dia 11. Por lá teremos outros MVPs, na track de .Net, como o grande Thiago Soares, falando de .Net e o futuro, e o Israel Aéce, falando de WCF (obviamente). Outros amigos por lá serão o Rodrigo Yoshima e o Alexandre Magno, também na track de Agile, além de outros. O sábado terá ainda uma track de Java, com o Paulo Silveira, que conheci no AgileBrazil. Figuras de peso abrem o evento, como o Nick Kallen, engenheiro do Twitter, que vai falar de escalabilidade, e o Douglas Crockford, ninguém menos do que o criador do JSON.

Domingo segue com tracks de arquitetura, casos de sucesso, e Ruby, que obviamente contará com o Akita. Uma das palestras que abre o evento é do Scott Ambler, falando sobre como escalar Agile. O Guilherme Silveira, da Caelum, que me chamou a palestrar, também estará lá, falando de REST. Aliás, o Guilherme esteve no AgileBrazil, e ele faz uma palestra de 45 minutos sem respirar. Juro. Vale a pena assistir.

Em resumo: o evento é imperdível, e eu não vou trabalhar a semana toda, já que logo em seguida tem TechEd. Eu já estava arrumando minha agenda pra ir, mesmo se não fosse convidado a palestrar. Vejo vocês lá.


Postado na(s) categoria(s) Eventos pelo Giovanni Bassi em 28 de junho de 2010 às 01:34 | Tags: , , ,

Quem é Giovanni Bassi

Giovanni Bassi Sou uma pessoa apaixonada por tecnologia e especificamente por .Net. Sou consultor independente especialista em .Net, focado em arquitetura e melhores práticas. Tenho dezenas de artigos publicados na .Net Magazine, revista da qual sou editor técnico. Ministro palestras e cursos de vez em quando, e quando dá tempo eu respiro um pouco. Mais detalhes nesta página.

Busca

Selos

Eu vou ao TechEd Brasil 2010, e você?

MVP

MCPD

MCSD

.Net Magazine

Abaixo ao if!

Calendário

«  setembro 2010  »
seteququsedo
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910
Ver detalhamento de posts no calendário

Blogs interessantes

    OPMLDownload OPML file

    Postagens recentes

    Comentários recentes

    Disclaimer / Aviso
    As opiniões colocadas neste blog são minhas e pessoais e não expressam necessariamente as opiniões de meus empregadores, pareceiros e amigos. Da mesma forma, os comentários feitos por leitores do blog não expressam a minha opinião.

    © Copyright 2010 .Net Unplugged
    Log in