tucaz

DevOpando em ambientes Windows com Performance Counters - Requests per Second

2012-11-30T22:00:00+00:00

Quando desenvolvimentos aplicaçoes, conhecer bem o ambiente em que fazemos o deploy é fundamental. Principalmente quando falamos de aplicaçoes web e abertas pra internet. Estas aplicaçoes estao mais expostas e sujeitas a todo tipo de situaçoes como um pico de acessos e até maldosos ataques. Geralmente esta tarefa é deixada para a equipe de infra-estrutura, mas cada vez mais os desenvolvedores estao se metendo nessa área e aprendendo a configurar e otimizar seus servidores.

Vamos DevOpar!

Performance Counters

Este é um assunto que gosto muito e que vou explorar agora começando com performance counters. Performance counters, como o próprio nome diz, sao contadores que o Windows e muitas aplicaçoes que rodam sobre ele disponibilizam pra nós. Por meio destes contadores é possível verificar desde o uso de CPU da máquina até informaçoes detalhadas sobre a execuçao do Garbage Collector em aplicaçoes .NET.

Performance Monitor

Para ter acesso aos contadores de performance basta digitar "perfmon" no prompt "Executar" do Windows:

que a janela principal do Perfomance Monitor se abrirá já com algumas informaçoes básicas sobre sua máquina:

Clicando em "Performance Monitor" ganhamos acesso a o que realmente nos interessa:

Através do botao existente na barra de tarefas é possível trocar o tipo do gráfico e mudar para um que nôs de os valores absolutos dos contadores que já traz, por padrao, a utilizaçao de CPU:

Requests Per Second / Requisiçoes Por Segundo

Agora que já nos ambientamos com nossa nova ferramenta de trabalho vamos começar a falar dos contadores em si. O primeiro que vou falar a respeito é Requests Per Second, ou na sigla, RPS.

Este contador é o mais básico e ainda um dos mais importante quando analisamos qualquer aspecto relacionado a performance em aplicaçoes Web. Ele nos fornece o número de requisiçoes que uma instância do .NET (comumente um site do IIS) está executando a cada segundo.

Baseado no número de requests podemos dizer se nossa aplicaçao irá ou nao aguentar a demanda prevista ou identificar o momento (número de requests) em que nossa aplicaçao começa a se comportar mal, por exemplo [1]. A partir deste contador é que a análise de todos os outros fará sentido.

Para incluí-lo na sua janela do performance monitor basta utilizar o botao "Adicionar" na barra de ferramentas.

É importante entender que todo contador está sempre associado a uma instância que será selecionada no momento que adicionamos o contador. Neste caso, uma instância é um site do IIS, mas em outros casos podemos encontrar o acumulado de todas as instâncias disponível em uma instância chamada _Global_ ou _Total_, um executável .NET ou até mesmo uma instância especifíca de um serviço exposto por meio de WCF.

Este contador está localizado dentro do grupo ASP.NET Applications com o nome de Requests/Sec [2].

Uma vez adicionado, você verá, em tempo real [3], o número de requisiçoes por segundo que seu site está atendendo. Na maioria das aplicaçoes este número é relativamente baixo nao passando de 5 ou 10 já que pra que este contador seja incrementado é necessário que as requests sejam executadas exatamente no mesmo segundo. Isto geralmente acontece em duas situaçoes: você tem vários usuários acessando sua aplicaçao ao mesmo tempo ou caso suas requisiçoes demorem muito pra terminar a execuçao.

Já em alguma aplicaçoes este número pode ser bem alto. O Tumblr por exemplo, atende cerca de 40 mil [4] requisiçoes em um dado segundo o que requer uma arquitetura bem desenhada e implementada.

Nos próximos posts sobre este assunto vou falar de contadores de exceptions, caching, memória e diversos outros que devem ser monitorados e medidos pra garantir a boa saúde de sua aplicaçao.

Era isso. :)

[1] Ele também serve pra você se gabar para seus amigos nerds já que construir uma aplicaçao que atende milhares de RPS nao é trivial

[2] A Microsoft pisou na bola na hora de nomear os contadores do Windows na versao em Português. O nome dos contadores foi traduzido. A maioria deles você consegue encontrar facilmente, mas alguns tem nomes totalmente toscos e por conta da ordenaçao alfabética contadores relacionados acabam ficando em posiçoes nao sequencias dentro de seus grupos o que é um pé no saco.

[3] Os contadores sao coletados em intervalos super baixos (1 em 1 segundo no Windows 8 Ultimate, por exemplo) o que, pra todos os efeitos, é em tempo real e este valor é configuável por meio das propriedades do Performance Monitor.

[4] Fonte - http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html

Como armazenar senhas de forma segura em sua aplicaçao - Parte 2

2012-11-30T22:00:00+00:00

Na primeira parte desta série abordei alguns conceitos básicos e terminei falando de hashing e como ele serve pra gerarmos um valor único e irreversível a partir de um input de dados.

Como utilizar hashing pra proteger nossa aplicaçao

Já que nao conseguimos reverter o valor gerado a partir de uma funçao de hashing como podemos utiliza-lo como forma de proteçao de senha?

public void CadastroUsuario(string login, string senha /* outros dados do usuário */)
{
    var hashSenha = GerarHash(senha);
    Usuarios.Armazenar(login, hashSenha /* outros dados do usuário */ )
}

public bool LoginEhValido(string login, string senha)
{
    var hashUsuarioArmazenado = Usuarios.RecuperarHash(login);
    var hashSenha = GerarHash(senha);

    return hashSenha == hashUsuarioArmazenado;
}

No momento do cadastro do usuário, ao invés da senha, armazenamos o hash resultante da senha do usuário como exemplificado no método CadastroUsuario
Na hora de verificar o login, como bons algoritmos de hashing garantem unicidade, basta comparar o hash armazenado com o hash resultando da senha informada pelo usuário pra verificar se ele é quem diz ser já que apenas a senha original terá o hash compatível com o armazenado

Além de garantirmos que mesmo que nossa base de dados caia em maos erradas ninguém terá acesso a senha original do usuário também garantimos que nós (mantenedores da aplicaçao) também nao teremos acesso o que também é muito bom já que a maioria dos usuários utiliza a mesma senha em mais de uma aplicaçao.

Criando um algorítmo simples de hashing

Pra entender melhor a idéia de um algorítmo desse tipo vamos implementar uma versao bem simplificada:

public static string GerarHash(string entrada)
{
    var hash = entrada.Sum(caracter => (int) caracter);
    return hash.ToString();
}

GerarHash("senha");  //resultado 527
GerarHash("SENHA");  //resultado 367
GerarHash("ddddM2"); //resultado 527

Podemos perceber algumas coisas neste método:

Mesmo inserindo uma entrada com o mesmo significado em portugûes ("senha" e "SENHA") obtemos dois hashes diferentes, o que é desejável, pois tratando-se de senhas, diferenciar maíusculas e mínusculas é uma maneira de gerar senhas mais complexas e difíceis de se adivinhar
Este algoritmo garante unicidade apenas em um pequeno grupo de entradas já que tanto "senha" quanto "ddddM2" geraram o mesmo resultado. Isto acontece, pois o algorítmo é muito simples e apenas soma o valor ASCIÎ de cada um dos caracteres da sequência de entrada
Ainda assim, podemos perceber também que é virtualmente impossível, a partir do hash, descobrir com certeza qual entrada originou o hash já que executamos uma sequência matemática que nos permite obter o mesmo resultado com mais de um input diferente.

Como vocês já devem ter concluído este nao é um algoritmo de hashing que devemos usar caso nosso objetivo seja garantir a segurança de nossa aplicaçao já que colisoes sao muito frequentes.

Partindo dai é que surgiu o MD5, um dos algorítmos mais utilizados hoje em dia pra geraçao de hashes. Em .NET ele está disponível nativamente por meio da classe MD5 existente no namespace System.Security.Criptography. Um exemplo de uso pode ser encontrado na página oficial de documentaçao no MSDN e o pseudo código e algumas implementaçoes simples na Wikipedia.

Apesar de MD5 ser um bom algorítmo ele já nao é mais considerado seguro e pode ser quebrado facilmente. Contudo existem outras maneiras de mesmo com MD5 garantir que as senhas de seus usuários estejam seguras e é sobre isso que vou falar no próximo post.

Até lá!

Como armazenar senhas de forma segura em sua aplicaçao - Parte 1

2012-11-02T16:00:00+00:00

Esse é um assunto básico e relativamente simples no contexto que vou apresentar. No entanto é algo largamente negligenciado por muitos sites e aplicaçoes que construimos e consumimos todo dia. Talvez pela aparente simplicidade.

Armazenar adequadamente as senhas dos nossos usuários é um dos muitos aspectos que compoe a segurança de nossas aplicaçoes e com poucas horas, ou até minutos, de estudo sobre o assunto é possível faze-lo de maneira bastante satisfatória.

Portanto, se você nao quiser fazer um papelao como o LinkedIn, que armazenava suas senhas em plaintext quando foi hackeado ou como o próprio Yahoo que também nao utilizava melhores praticas é fundamental levar este assunto a sério.

Conceitos Básicos

A idéia por trás do armazenamento seguro de senhas é garantir que mesmo que alguém nao autorizado tenha acesso a seu banco de dados nao irá conseguir tirar proveito dos dados que acessou.

A fim de atingir esse objetivo a prática mais utilizada (se nao única) é a de criptografia. De acordo com a definiçao do Wikipedia criptografia significa:

O estudo dos princípios e técnicas pelas quais a informaçao pode ser transformada da sua forma original para outra ilegível, de forma que possa ser conhecida apenas por seu destinatário

Em termos práticos, criptografar uma informaçao significa transformá-la, por meio de um algorítmo, em qualquer outra informacao diferente da original tornando possível a transmissao ou armazenamento de maneira segura.

Utilizamos criptografia reversível como 3DES ou AES em cenários onde recuperar a informaçao original é fundamental, como no caso de armazenamento de informaçoes confidenciais como por exemplo números de cartoes de crédito [1]. Sem que o número do cartao de crédito do cliente seja recuperado é impossível efetuar uma cobranca.

Um ponto importante a respeito de criptografia reversível é que a informaçao resultante do processo tem um tamanho variável e geralmente próximo do tamanho da informaçao original portanto uma entrada de dados com tamanho de 3mb, por exemplo, teria uma saída criptografada de aproximadamente 3mb, também.

Hashing

Contudo, em nosso cenário de armazenamento de senhas, nao estamos realmente interessados em conhecer a informaçao original (a senha do usuário), mas sim em garantir que ele tenha digitado-a corretamente quando quiser acessar nossa aplicaçao.

Ai entra um outro tipo de algoritmo criptográfico chamado de hashing.

Funçoes de hashing recebem uma entrada de dados de tamanho variável e através de um algoritmo fornecem uma saída de dados única e com tamanho fixo e irreversível nao importando o tamanho da entrada. Tomando MD5 como exemplo, uma entrada de dados de 100kb ou 3mb iriam produzir uma saída única e diferente para cada uma das entradas de dados com um tamanho de fixo 128 bits.

A unicidade da saída de dados é garantida até certo ponto e varia de acordo com o algoritmo utilizado e a entrada de dados passada para a funçao. No entanto as chances de colisao (mais de uma entrada mapear para a mesma saida de dados) sao pequenas o suficiente para ignorarmos na maioria dos casos. Ainda no caso de MD5, a primeira colisao apareceria depois de cerca de 2e64 hashes gerados.

Conclusao

Portanto, em nosso cenário a melhor saída é a utilizaçao de uma funçao de hashing ao invés de criptografia. Ainda assim, existem outros cuidados que devemos tomar no uso de funcoes de hashing e é sobre isso que falarei no próximo post quando mostrarei como aplicar tais funçoes no armazenamento e validaçao da senha de um usuário.

Até lá :)

[1] - Armazenar cartoes de crédito de seus clientes nao é uma boa idéia. Quando devemos fazer a cobrança apenas uma vez normalmente nao armazenamos esse número, mas no caso de cobranças recorrentes este é um mal necessário e existem outras regras além de criptografia pra garantir que este processo seja seguro.

Validando domínio de maneira simples em C#

2012-10-25T22:00:00+00:00

Faz algum tempo que nao começo um projeto novo onde eu tenha a oportunidade de pensar em todos detalhes envolvidos na arquitetura do sistema. Esses dias comecei um novo projeto e a oportunidade apareceu. Junto com ela veio também aquele sentimento de perfeccionismo que nos obriga a achar a melhor maneira possível pra resolver um problema e muitas vezes acaba fazendo com que muito tempo seja perdido e nenhuma soluçao seja encontrada já que somos totalmente livres pra fazer o que quisermos.

Precisava pensar em como fazer pequenas validaçoes em meus objetos de domínio pra garantir que nao fiquem em um estado inválido.

Dessa vez decidi que nao ia deixar isso acontecer e tomei a decisao mais pragmática possivel: vou achar algo bacana pronto e por pra rodar. Rapidinho achei a biblioteca FluentValidation que de acordo com o próprio autor faz o que eu precisava.

A small validation library for .NET that uses a fluent interface and lambda expressions for building validation rules for your business objects - Fluent Validation

E um exemplo básico de uso retirado da documentaçao:

using FluentValidation;

public class CustomerValidator: AbstractValidator<Customer> {
  public CustomerValidator() {
    RuleFor(customer => customer.Surname).NotEmpty();
    RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name");
    RuleFor(customer => customer.Company).NotNull();
    RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);
    RuleFor(customer => customer.Address).Length(20, 250);
    RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode");
  }

  private bool BeAValidPostcode(string postcode) {
    // custom postcode validating logic goes here
  }
}

Customer customer = new Customer();
CustomerValidator validator = new CustomerValidator();
ValidationResult results = validator.Validate(customer);

bool validationSucceeded = results.IsValid;
IList<ValidationFailure> failures = results.Errors;

No entanto, seguindo a idéia de manter as coisas simples, construir uma nova classe só pra colocar minhas validaçoes me pareceu demais. Pra nao perder mais tempo e resolver de vez resolvi implementar minha soluçao.

Primeiro aos testes:

[TestFixture]
public class NovoUsuarioTest
{
    [Test, TestCaseSource("Cenarios")]
    public string validacoes_basicas(NovoUsuario usuario)
    {
        var erros = new List<string>();
        var valido = usuario.IsValid();

        return usuario.Errors.First();
    }


    private static IEnumerable Cenarios()
    {
        yield return new TestCaseData(new NovoUsuario() { Senha = "abc", ConfirmacaoSenha = "abc" })
            .SetName("Email obrigatório")
            .Returns(Mensagens.Usuario.EmailEhObrigatorio);

        yield return new TestCaseData(new NovoUsuario() { Email = "abc@gmail.com", ConfirmacaoSenha = "abc" })
            .SetName("Senha obrigatória")
            .Returns(Mensagens.Usuario.SenhaEhObrigatoria);

        yield return new TestCaseData(new NovoUsuario() { Email = "abc@gmail.com", Senha = "abc" })
            .SetName("Confirmaçao de senha obrigatória")
            .Returns(Mensagens.Usuario.ConfirmacaoSenhaEhObrigatoria);

        yield return new TestCaseData(new NovoUsuario() { Email = "abc@gmail.com", Senha = "abc1", ConfirmacaoSenha = "abc" })
            .SetName("Senha e confirmaçao devem ser iguais")
            .Returns(Mensagens.Usuario.SenhaEConfirmacaoDevemSerIguais);
    }
}

Usei TestCases do NUnit pra descrever os 4 cenarios que queria testar. Na sequencia desenhei a biblioteca pensando em como gostaria de consumi-la:

public class NovoUsuario : ValidationBase<NovoUsuario>
{
    public string Id { get; set; }
    public string Email { get; set; }
    public string Senha { get; set; }
    public string ConfirmacaoSenha { get; set; }

    public override bool IsValid()
    {
        Require(x => x.Email, Mensagens.Usuario.EmailEhObrigatorio);
        Require(x => x.Senha, Mensagens.Usuario.SenhaEhObrigatoria);
        Require(x => x.ConfirmacaoSenha, Mensagens.Usuario.ConfirmacaoSenhaEhObrigatoria);
        Enforce(x => x.Senha == x.ConfirmacaoSenha, Mensagens.Usuario.SenhaEConfirmacaoDevemSerIguais);

        return base.Errors.Count == 0;
    }
}

Bem simples né? A idéia é ter apenas dois métodos:

Require -> Garante que uma propriedade esta preenchida
Enforce -> Recebe uma lambda que permite passar validaçoes mais elaboradas, mas ainda assim nao tao complicadas

Por último, o código que fez meus testes passarem:

public abstract class ValidationBase<T> where T : ValidationBase<T>
{
    public List<String> Errors { get; private set; }

    public ValidationBase()
    {
        this.Errors = new List<string>();
    }

    protected void Require(Expression<Func<T, object>> property, string message)
    {
        var prop = property.Compile();
        var value = prop((T)this);

        var isValid = false;

        if (value == null)
            isValid = false;
        else if (value.GetType() == typeof(String))
            isValid = !String.IsNullOrWhiteSpace(value.ToString());
        else if (value.GetType() == typeof(Guid))
            isValid = (Guid)value != Guid.Empty;
        else if (value.GetType() == typeof(int))
            isValid = (int)value == 0;
        else if (value.GetType() == typeof(decimal))
            isValid = (decimal)value == 0;
        else if (value.GetType() == typeof(DateTime))
            isValid = (DateTime)value == DateTime.MinValue;         

        if (!isValid)
            this.Errors.Add(message);
    }

    protected void Enforce(Func<T, bool> validation, string message)
    {
        var isValid = false;            

        if (validation != null)
            isValid = validation.Invoke((T)this);
        else
            throw new ArgumentNullException("validation");

        if (!isValid)
            this.Errors.Add(message);
    }

    public abstract bool IsValid();
}

Simples, mas poderosa o suficiente pra me oferecer que eu preciso agora.

Quando eu precisar de mais conversamos novamente sobre o assunto. :)

Blog de volta e em nova plataforma

2012-10-20T18:00:00+00:00

Depois de quase dois anos sem postar nada no blog decidi colocar ele de volta pra funcionar.

Pra dar uma animada (e aprender algo novo) sai do wordpress pra uma soluçao mais manual, mas mais completa no meu ponto de vista.

Agora estou usando:

Windows Azure (de grátis!) com Ubuntu como host
Jekyll + Git para geraçao do conteúdo
Disqus pra comentários
Qualquer editor de texto (até mesmo o notepad!!!) pra escrever os posts utilizando markdown que é BEM egal

Mudei também a cara dele com meu próprio layout mesmo sendo péssimo designer em favor de algo mais clean.

Espero que gostem e avisem em caso de qualquer problema que eu tenha deixado passar.

Até! :)

Começando a aprender F# com: Ubuntu, Mono e Vim

2011-01-10T21:58:47+00:00

Já faz algum tempo que estou meio de saco cheio de desenvolvimento comercial tradicional que a maioria de nós, desenvolvedores, está acostumado a fazer. De uma forma ou de outra, exceto em projetos excepcionais tudo é uma variação de CRUD o que é um pé no saco pra quem gosta de código. Chega uma hora que a gente começa a procurar maneiras diferentes (não necessariamente melhores) de fazer a mesma coisa só pra acabar com o tédio. Isso estava me incomodando.

Há alguns meses quando este sentimento veio novamente decidi que iria tentar algo diferente. Foi ai que comecei com o combo título deste post. Uma mudança radical de ares.

Não sou o primeiro e com certeza não serei o último.

Apesar de trabalhar com Windows e depender dele pro meu ganha pão adotei o Ubuntu como sistema operacional padrão deixando o Windows em uma VM [1] apenas para trabalho e comecei a estudar F# que é uma linguagem com paradigma funcional que é completamente diferente de C#, Java e parentes próximos. Não bastasse a mudança de sistema operacional e de paradigma decidi também aprender mais a respeito de shell e editores de texto pra me livrar mais ainda dos atalhos que uma IDE como o VS proporcionam e adotei o VIM como editor de texto.

Nest post vou mostrar como montar um ambiente como o meu e os primeiros (primeiros mesmo, nada avançado) passos nessa estrada de aprendizado. Se tudo der certo e eu não desistir transformo numa série pra poder compartilhar meu aprendizado e com a colaboração de vocês aprender mais sobre o assunto.

Tudo que estou fazendo é no Ubuntu 10.10, mas deve funcionar com uma boa parte dos *nix por ai.

Instalando F# com Mono

Provavelmente o Linux que você tem instalado já deve ter o mono instalado, portanto não precisamos nos preocupar com esta etapa. De qualquer forma, só pra garantir abra o shell (Terminal) veja se você está realmente como o Mono instalado e qual sua versão:

mono -V

Se tudo estiver certo teremos algo parecido com isso:

Mono JIT compiler version 2.6.7 (Debian 2.6.7-3ubuntu1)
Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com
    TLS:           __thread
    GC:            Included Boehm (with typed GC and Parallel Mark)
    SIGSEGV:       altstack
    Notifications: epoll
    Architecture:  amd64
    Disabled:      none

Caso ele não esteja instalado basta ir ao Ubuntu Software Center [2] para instalá-lo ou baixá-lo no site oficial.

Com Mono instalado corretamente e acessível de qualquer lugar precisamos agora baixar a última versão disponível da biblioteca e compilador FSharp. Temos três opções para a instalação:

Efetuar o download do código fonte, compilá-lo e efetuar a instalação
Baixar um pacote cross-platform que faz a instalação de tudo
Baixar o pacote oficial compilado, efetuar a instalação e configurar as variáveis de ambiente “manualmente”

Vamos com a terceira opção, pra ver onde vai cada coisa e como cada um dos executáveis funciona.

A última versão disponível no momento deste post é a 2.0.0.0 de Novembro de 2010.

Como somos usuários ninjas de Linux vamos efetuar o download via linha de comando com wget.

wget http://download.microsoft.com/download/4/5/B/45BD9FBC-22BA-4B45-84B7-17D1AD0122A1/fsharp.zip

Terminado o download, um pacote zip, extraimos todo o conteúdo pra uma pasta qualquer.

unzip fsharp.zip

Agora devemos ter todo o conteúdo do zip extraido em uma pasta chamada FSharp-2.0.0.0.

Antes de instalar sugiro mover a pasta com o conteúdo extraido do zip para um local mais apropriado para este tipo de arquivos já que é a partir desta pasta que iremos fazer referência mais pra frente aos executáveis do FSharp. Eu utilizo /usr/lib/ [3]. Além de mover, vamos renomear a pasta de destino apenas para fsharp a fim de deixar tudo mais simples.

sudo mv FSharp-2.0.0.0/ /usr/lib/fsharp/
cd /usr/lib/fsharp/

Agora para instalar basta executar:

cd fsharp
sudo sh install-mono.sh

Este comando provavelmente retornará um erro indicando que a DLL não pôde ser adicionada ao GAC por conta de seu strongname. O que acontece é que a versão compilada que baixamos está com uma assinatura para o .NET Framework do Windows então antes de conseguir instalar o FSharp no Mono devemos baixar um arquivo.snk próprio para ele e ai sim executar novamente o setup.

wget -O mono.snk https://github.com/mono/mono/raw/master/mcs/class/mono.snk --no-check-certificate
sudo sh install-mono.sh

Dando tudo certo, devemos receber uma mensagem de sucesso:

-- Resigning FSharp.Core.dll with mono.snk
Assembly bin/FSharp.Core.dll signed.
-- Installing FSharp DLLS into the GAC
Installed bin/FSharp.Core.dll into the gac (/usr/lib/mono/gac)

Pra testar se tudo der certo, ainda de dentro do diretório onde instalamos o FSharp, podemos executar:

mono bin\fsi.exe

Se tudo estiver OK vamos entrar no FSharp Interactive que é uma console REPL pra F# muito legal:

Microsoft (R) F# 2.0 Interactive build 2.0.0.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

>

Podemos também fazer o tradicional “Hello World”:

> printfn "Hello World!";;
Hello World!
val it : unit = ()

Pronto!

Tecnicamente temos o FSharp instalado com sucesso e pronto para usar. No entanto, tanto o compilador (fsc.exe) e o REPL (fsi.exe) não fazem parte do PATH configurado em nosso Linux. Desta forma, ele está apenas acessível a partir do diretório onde está localizado.

Pra resolver isso vamos baixar o pacote de ferramentas adicionais para FSharp que irá nos prover algums aliases que permitirão o acesso as ferramentas a partir de qualquer diretório.

Dessa vez, como este pacote está hospedado no Codeplex, temos que efetuar o download do pacote “Additional scripts and tools only (.tgz archive)” manualmente localizado em http://fsxplat.codeplex.com/releases/view/55463.

Feito o download podemos voltar ao nosso querido shell e instalar o pacote de bonus.

cd ~/Downloads
mkdir fsharp-bonus
tar -xvzf fsharp-bonus.tgz -C fsharp-bonus
cd fsharp-bonus
sudo bash install-bonus.sh

Este script de instalação espera que as DLLs do FSharp estejam na pasta /usr/lib/fsharp. No entanto, no nosso caso elas se encontram em /usr/lib/fsharp/bin, portanto caso o script solicite esta informação, fica fácil de prover. :)

Feito isso é hora de testar e já podemos chamar fsharpi de qualquer lugar no shell:

tucaz@tucaz-nb:~$ fsharpi

Microsoft (R) F# 2.0 Interactive build 2.0.0.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

>

Agora podemos chamar tanto o REPL quanto o compilador a partir de qualquer diretório já que os alias foram devidamente criados e adicionados ao PATH.

Primeiro Hello World com Vim

Agora que temos todo o ambiente instalado (o que na minha opinião é um dos primeiros grandes obstáculos no aprendizado de uma nova linguagem) podemos fazer nosso primeiro Hello World e gerar uma DLL .NET com F#!

Primeiro, vamos definir um diretório de trabalho onde vamos colocar todos nossos projetos. Eu costumo usar um diretório chamado Workspace dentro do meu profile:

cd ~
mkdir Workspace
cd Workspace
mkdir HelloWorldFSharp
cd HelloWorldFSharp

Criado o diretório, criamos também nosso primeiro arquivo com código fonte FSharp utilizando o Vim [4]:

vim HelloWorldFSharp.fs

Isso cria um arquivo chamado HelloWorldFSharp.fs (assumindo que um não exista ou abre para edição caso ele exista) e o abre no nosso editor de texto funcionando dentro de um terminal shell, que pra um usuário Windows (que não tenha usado o Edit do DOS) é algo geralmente desconhecido.

O Vim (como o Vi) oferece basicamente dois modos de trabalho: modo de comando e edição/inserção de texto. Quando abrimos um arquivo, por padrão temos o modo de comando onde o texto digitado não é o que vai para o arquivo, mas sim interpretado como um comando (a seguir).

Para entrar no modo de edição de texto digitamos i ou apertamos a tecla insert do teclado. Note que o texto --INSERT-- irá aparecer no canto esquerdo inferior da tela indicando que agora estamos no modo de inserção de texto. Esta área é destinada aos comandos e mensagens do editor.

Estando no modo de edição vamos escrever nosso Hello World!

#light 

printfn "Hello World!"

Com “todo” nosso código completo vamos sair do modo de edição (e voltar ao modo comando) apertando ESC. Para salvar e sair digitamos o comando :wq (write and quit) e enter retornando ao terminal.

Pra compilar nosso código fonte e gerar o primeiro .exe no Linux:

fsharpc HelloWorldFSharp.fs

Obtendo a resposta:

Microsoft (R) F# 2.0 Compiler build 2.0.0.0
Copyright (c) Microsoft Corporation. All Rights Reserved.
tucaz@tucaz-nb:~/Workspace/HelloWorldFSharp$ ls
HelloWorldFSharp.exe  HelloWorldFSharp.fs
tucaz@tucaz-nb:~/Workspace/HelloWorldFSharp$

E por último, vamos executar nosso primeiro programa .NET em Linux:

mono HelloWorldFSharp.exe
Hello World!

Fim!

Neste post vimos como instalar Mono/F# no Linux e como criar nosso primeiro programa Hello World em F# utilizando o Vim. No próximo, quero começar a falar mais a respeito de F# e Vim e deixar para trás questões de ambiente.

Até lá!

[1] – Estou utilizando Ubuntu 10.10 AMD64 rodando em um notebook Core i7 (2.66ghz) com 6gb de memória RAM sendo que 2gb ficam exclusivos para VM rodando no Virtual Box. A performance é ótima!

[2] – Menu Principal –> Applications –> Ubuntu Software Center

[3] – Alguma outra sugestão?

[4] – Se o Vim não estiver instalado, basta executar “sudo apt-get install vim” para instalá-lo

Lendo e consumindo XML com dynamic em C# 4

2010-11-18T20:57:30+00:00

Sei que faz tempo que não posto então aqui vai um post rápido, mas com conteúdo (espero que vocês vejam dessa forma também). Finalmente comecei a trabalhar efetivamente com C# 4 e por coincidência (ou não) já precisei de dynamic objects pra resolver um problema.

Meu sistema recebe como entrada alguns arquivos XML para serem processados e transformados em outros objetos posteriormente. XML é um saco e é definitivamente uma das coisas que eu mais odeio em desenvolvimento de software. Tudo com XML é trabalhoso. Sendo assim criei uma pequena Lib que transforma XML em objetos dinamicos pra eliminar a necessidade de lidar com nós e atributos diretamentes e também permitir futuras implementacões.

Com XmlToObjectParser é possível:

<?xml version="1.0" encoding="ISO-8859-1"?>
<catalog>
  <cd country="USA">
    <title>Empire Burlesque</title>
    <artist>Bob Dylan</artist>
    <price>10.90</price>
  </cd>
  <cd country="UK">
    <title>Hide your heart</title>
    <artist>Bonnie Tyler</artist>
    <price>10.0</price>
  </cd>
  <cd country="USA">
    <title>Greatest Hits</title>
    <artist>Dolly Parton</artist>
    <price>9.90</price>
  </cd>
</catalog>

var numberOfCDsinCatalog = catalog.catalog.cd.Count; //Retorna 3
var titleFromUKCD = catalog.catalog.cd[1].title; // Retorna "Hide your heart"

Bem mais legível e prático de usar, na minha opinião.

O projeto e a DLL compilada estão no GitHub assim como a documentacão e informacões adicionais.

Enjoy! :)

Performance: NHibernate versus ADO.NET

2010-08-31T22:18:21+00:00

Disclaimer

Os testes neste post apresentados não representam uma amostra exata ou fidedigna que represente uma condição real de acesso a dados de uma aplicação a fim de comparar a performance das duas tecnologias. A idéia é apenas mostrar alguns dados e exemplos com o objetivo de dismistificar a idéia de que ORM é uma ferramenta lenta e estes testes são apenas um exercício.

Sou usuário de NHibernate e defendo o uso de ORM’s portanto as conclusões apresentadas com certeza não são as mais imparciais possíveis.

Motivado por esta thread no DNA hoje decidi fazer alguns testes de perfomance pra comparar acesso a dados utilizando ADO.NET nativo (queries AdHoc e Stored Procedures) versus NHibernate.

Sempre rolam diversas discussões a respeito do assunto e a conclusão que geralmente se chega é de que qualquer ORM vai ser mais lento do que uma chamada nativa. É uma conclusão óbvia já que utilizar um ORM é adicionar uma camada de abstração a mais dentro da nossa aplicação. No entanto, até então eu nunca havia efetuado nenhuma medição pra ver qual a diferença de performance.

Todos os testes foram executados na minha máquina com código compilado em modo Release com banco de dados Sql Server 2008 também local.

Vamos aos testes.

Cenário de testes

Criei uma tabela (Product) e populei com cerca de 500 registros vindos do AdventureWorks (banco de dados exemplo do SqlServer).

Contra essa tabela executei duas categorias de testes:

Carregar todos os registros da tabela em um List<>
Carregar apenas um registro

Pra ficar mais interessante fiz algumas variações dos testes:

Query AdHoc/Inline
Query AdHoc/Inline com hidratação[1] via reflection
Query utilizando uma procedure
NHibernate com LINQ
NHibernate com HQL
NHibernate com Criteria
Nhibernate com Projections

Como rodando uma única vez não foi possível obter dados suficientes, executei cada teste dentro de um loop com 1000 (numberOfIterations = 1000) iterações que resultou no código abaixo:

Método principal:

static void Main(string[] args)
{
    for (int i = 1; i <= 3; i++)
    {
        Console.WriteLine("Test " + i.ToString());
        Console.WriteLine("======================");

        SqlAdHocAllProducts();
        SqlAdHocAllProductsWithReflection();
        SProcAllProducts();
        NHibernateAllProductsWithLinq();
        NHibernateAllProductsWithHql();
        NHibernateAllProductsWithCriteria();
        NHibernateAllProductsWithProjections();

        SqlAdHocOneProduct();
        SqlAdHocOneProductWithReflection();
        SProcOneProduct();
        NHibernateOneProduct();

        Console.WriteLine();
    }

    Console.ReadLine();
}

Um dos métodos usando Sql AdHoc e outro usando NHibernate:

private static void SqlAdHocAllProducts()
{
    List<Product> allProducts = null;

    var connectionString = "Data Source=(local);Integrated Security=SSPI;Database=TDC2010;";
    var select = @"SELECT P.Id, P.Description, P.Name, P.Price FROM dbo.Product P";

    var connection = new SqlConnection(connectionString);
    connection.Open();

    Stopwatch watch = new Stopwatch();
    watch.Start();

    for (int i = 0; i < numberOfIterations; i++)
    {
        allProducts = new List<Product>();
        var command = new SqlCommand(select, connection);
        var reader = command.ExecuteReader();

        while (reader.Read())
        {
            allProducts.Add(new Product()
                {

                    Id = Convert.ToInt32(reader["Id"]),
                    Name = Convert.ToString(reader["Name"]),
                    Description = Convert.ToString(reader["Description"]),
                    Price = Convert.ToDecimal(reader["price"])
                });
        }

        reader.Close();
    }

    watch.Stop();

    connection.Close();
    connection.Dispose();

    Console.WriteLine(
        "Loading " + allProducts.Count + " Products with Sql AdHoc took " + watch.ElapsedMilliseconds + " ms");
}

private static void NHibernateAllProductsWithLinq()
{
    List<Product> allProducts = null;

    var session = CreateForSqlServer().OpenSession();

    Stopwatch watch = new Stopwatch();
    watch.Start();

    for (int i = 0; i < numberOfIterations; i++)
    {
        allProducts = session.Linq<Product>().ToList();
    }

    watch.Stop();

    session.Close();

    Console.WriteLine(
        "Loading " + allProducts.Count + " Products with NHibernate took " + watch.ElapsedMilliseconds + " ms");
}

Vou omitir o restante dos métodos para evitar duplicações já que eles são apenas variações dos dois exemplos acima.

Resultado Geral

Análise dos Resultados

Stored Procedures versus Queries AdHoc/Inline [500 registros]

A diferença entre o uso de stored procedures e queries AdHoc é praticamente inexistente. A diferença média medida foi de menos de 1%.

Isso acontece, pois não existe complexidade suficiente neste tipo de query para que a armazenagem do plano de execução no banco de dados faça diferença.

Portanto, na grande maioria dos cenários Stored Procedures não são necessárias.

NHibernate versus NHibernate [500 registros]

Na média, todas as variações de consulta utilizando NHibernate também tiveram mais ou menos o mesmo resultado (~1500ms) com exceção do uso de Projections, que levou o dobro (~3000ms) do tempo.

Não conheço o NHibernate suficiente pra afirmar com 100% de certeza o motivo, mas acredito que seja pelo fato de esse tipo de query retornar Arrays bidimensionais que são criados e redimensionados em runtime até que todos os itens possam ser acomodados.

NHibernate versus ADO.NET [500 registros]

Este e o comparativo mais importante. Carregando (e hidratando) 500 registros o ADO.NET é cerca de 30% mais rapido do que o NHibernate. A causa dessa discrepância é uma só e se chama reflection.

Apesar de todas as otimizações o NHibernate utiliza-se de reflection para efetuar a hidratação[1] de todos os objetos e é dai que vem a queda de performance que fica clara quando executamos queries AdHoc usando hidratação via reflection conforme o código abaixo.

private static void SqlAdHocAllProductsWithReflection()
{
    List<Product> allProducts = null;

    var connectionString = "Data Source=(local);Integrated Security=SSPI;Database=TDC2010;";
    var select = @"SELECT P.Id, P.Description, P.Name, P.Price FROM dbo.Product P";

    var connection = new SqlConnection(connectionString);
    connection.Open();

    Stopwatch watch = new Stopwatch();
    watch.Start();

    for (int i = 0; i < numberOfIterations; i++)
    {
        allProducts = new List<Product>();
        var command = new SqlCommand(select, connection);
        var reader = command.ExecuteReader();

        while (reader.Read())
        {
            var newProduct = Activator.CreateInstance<Product>();
            SetProperty(newProduct, "Id", Convert.ToInt32(reader["Id"]));
            SetProperty(newProduct, "Description", Convert.ToString(reader["Description"]));
            SetProperty(newProduct, "Name", Convert.ToString(reader["Name"]));
            SetProperty(newProduct, "Price", Convert.ToDecimal(reader["Price"]));
            allProducts.Add(newProduct);
        }

        reader.Close();
    }

    watch.Stop();

    connection.Close();
    connection.Dispose();

    Console.WriteLine(
"Loading " + allProducts.Count + " Products with Sql AdHoc and Reflection took " + watch.ElapsedMilliseconds + " ms");
}

private static void SetProperty(object instance, string property, object val)
{
    Type t = instance.GetType();
    var prop = t.GetProperty(property, BindingFlags.Instance | BindingFlags.Public);
    prop.SetValue(instance, val, null);
}

Este código quando executado demora cerca de 6000ms, ou 4 vezes mais, do que o código executado pelo NHibernate.

Mas por que a diferença não é de 30%? Porque o NHibernate possui otimizações quanto ao modo de hidratar um objeto via reflection. No meu código acima podemos ver, por exemplo, que toda vez que chamo o método SetProperty o Type da propriedade a ser refletida ainda não está criado. Provavelmente o NHibernate deve manter cache deste tipo de informação (e de outras) a fim de otimizar o processo de hidratação das entidades.

Stored Procedures versus Queries AdHoc/Inline [1 registro]

Mesmo resultado do cenário onde 500 registros são carregados. Não há diferença.

NHibernate versus ADO.NET [1 registro]

Aqui a diferença é gigantesca sendo de quase 4000% a favor do NHibernate. Isso acontece, pois o NHibernate implementa cache nível 1 nativamente então dentro de uma mesma ISession o objeto é carregado apenas uma vez enquanto com ADO.NET é necessário ir ao banco e carregar o objeto diversas vezes.

Conclusões

Olhando para os números apenas, em casos onde diversos registros precisam ser carregados, ADO.NET nativo oferece uma performance superior e parece ser a escolha óbvia. No entanto:

Os testes com NHibernate foram executados utilizandos exemplos simples e sem qualquer tipo de otimização.
NHibernate oferece nativamente cache de resultados de queries e cache nível 2 que se utilizados iriam exibir um resultado bem próximo ao cenário “NHibernate versus ADO.NET [1 registro]” onde o NHibernate é 4 vezes mais rápido.
ADO.NET oferece um custo de desenvolvimento e manutenção altissimo e este custo torna-se ainda maior se utilizado com Stored Procedures que transformam o cenário em algo totalmente caótico de gerenciar devido a dificuldade de manter a rastreabilidade desses diabinhos malignos.

No caso de sistemas OLTP onde as transações carregam unidades individuais e/ou pequenas coleções de entidades por sessão, NHibernate não só é mais rápido como também oferece muito mais flexibilidade pra lidar com praticamente todos os cenários existentes. Este post do Ayende mostra 25 funcionalidades importantes (cache, gerenciamento de concorrência, etc) que você vai precisar quando estiver lidando com dados e que custariam muito caro (tempo e complexidade) caso você queira escreve-las “na mão”.

Em cenários de aplicações de internet onde o número de leituras é infinitamente superior ao número de escritas no banco de dados deve se utilizar cache no front end (IIS), portanto o tempo que se leva pra montar uma página é irrelevante. Mesmo que você carregasse os dados de um servidor remoto via conexão discada não faria diferença uma vez que os dados estivessem em cache.

Por último, se você se encontrar em uma situação utilizando NHibernate onde o acesso a dados é o gargalo da sua aplicação seu problema não é o NHibernate (a não ser que você tenha usado-o de maneira totalmente absurda, mas a probabilidade de você fazer o mesmo com ADO.NET é grande também). Nestes cenários o problema não é o acesso a dados em si, mas o resto da arquitetura que não escala de maneira adequada seja por meio de cache, processamento assincrono, filas, etc.

Sendo assim, acredito que podemos concluir que não faz sentido algum no meio do ano de 2010 utilizar queries AdHoc ou Stored Procedures em aplicações LoB. :)

O código completo utilizado está no GitHub e pode ser acessado online ou baixado em formato zip.

[1] – Hidratação é o processo de preenchimento (filling) das propriedades de uma entidade

Material da palestra no TDC2010 - ORM: Por que isso te interessa?

2010-08-26T19:09:38+00:00

No último fim de semana rolou em São Paulo o TDC2010 organizado pela Globalcode. Fui convidado a palestrar na trilha de .NET pelo @giovannibassi pra falar um pouquinho sobre ORM e porque é uma boa idéia usá-lo.

Abaixo estão os slides da minha palestra, que não fazem muito sentido por si só, mas que tem umas imagens divertidas!

ORM: Por que isso te interessa? (TDC2010) from tucaz

Em um dos últimos slides tem uma porção de links muito legais sobre NHibernate então pra quem não quiser ter o trabalho de ver os slides ai vai:

http://nhforge.org/ -> NHibernate official website
http://fluentnhibernate.org/ -> Fluent Mappings for Nhibernate
http://nhprof.com/ -> NHibernate Profiler with 30 day trial
http://www.summerofnhibernate.com/ -> More than 14 hours of free videos
http://www.manning.com/kuate/ -> “NHibernate In Action” Book by Manning
http://ayende.com/Blog/category/510.aspx -> NHibernate @ Ayende’s
http://tinyurl.com/25reasons -> 25 reasons NOT to write yout own ORM @ Ayende’s
http://fabiomaulo.blogspot.com/search/label/NHibernate -> NHibernate @ Fabio Maulo’s
http://blogs.hibernatingrhinos.com/nhibernate/ -> NHibernate Blog
http://code.google.com/p/unhaddins/ -> unhaddins, Unofficial addins for Nhibernate

Além dos slides, coloquei no GitHub também o código fonte do projetinho que usei na demo que fiz. Apesar de ser uma demo, o código serve como referência pra começar a utilizar o NHibernate e FluentMapping e ter uma idéia de algumas features bem legais que ele oferece.

Download do zip com o código.

Palestraram também, da Stefanini, @vquaiato na trilha de Ruby e .NET, @alnascimento e @manoelp em Agile, @vcavalcante em .NET e @jorgediz em Testes.

Por último, mas não menos importante eu queria deixar registrado meu agradecimento ao Oren Eini (a.k.a. Ayende Rahien) pelos cupons de desconto e licensa do NHProf que distribui ao final da palestra e também a Candace da Manning Publications pelas cópias dos eBooks “NHibernate In Action” que também dei de brinde. Muito obrigado pelas contribuições a comunidade! :)

Now in English so I can make this public to English speakers too. Thanks to Oren Eini (a.k.a Ayende Rahien) for the discount coupons and NHProf license that I gave out and to Candace from Manning Publications for the copies of “NHibernate In Action” that were also given at the event. You guys are amazing. Thanks a lot for contributing with this growing community! :)

Ninject, StructureMap e Padrões de Injeção de Dependência

2010-08-04T00:57:56+00:00

Este post foi motivado por esta thread no DNA e por essa question no StackOverflow.com a respeito de um problema que encontrei nesta última semana em um cenário relativamente complexo de injeção de dependência.

Contexto

A arquitetura em questão utiliza injeção de dependência com base em interfaces, ou seja, todas as dependências das minhas classes são sempre pra interfaces (contratos) e nunca para classes concretas (implementação) exatamente como manda o figurino.

Meu domínio é o padrão: carrinho de compras com Pedido e seus itens. Uma classe é responsável por efetuar o processamento do pedido (GeradorPedido). Ela executa todos os procedimentos necessários para que um pedido seja gerado de maneira correta, dentre eles aplicar um determinado fator de ajuste de preços dos itens acordo com a loja onde o pedido foi vendido. Este fator de ajuste é determinado pela classe Precificador e deve ser desconhecido para o restante dos outros objetos a fim de não violar o SRP.

O diagrama abaixo representa as classes envolvidas e suas dependências:

Como aplicar este fator ao preço do item não é responsabilidade do GeradorPedido, sempre que uma instância de GeradorPedido é criada, injeto via construtor uma nova instância de Precificador pra ser usado quando necessário. Neste caso, temos uma dependência direta de GeradorPedido para IPrecificador que é resolvida em tempo de execução.

Tudo estava sendo resolvido utilizando Ninject:

MyModule.cs

public class MyModule : NinjectModule
{
    public override void Load()
    {
        Bind<IPrecificador>().To<Precificador>();
        Bind<IGeradorPedido>().To<GeradorPedido>();
    }
}

UnitTest1.cs

[TestMethod]
public void consegue_resolver_GeradorPedido()
{
    MyModule module = new MyModule();
    StandardKernel kernel = new StandardKernel(module);
    var geradorPedido = kernel.Get();

    Assert.IsNotNull(geradorPedido);
}

Precificador.cs

class Precificador : IPrecificador
{
    private decimal _fatorAjuste;

    public Precificador()
    {
        _fatorAjuste = 10m;
    }

    public decimal CalcularPreco(ItemPedido item)
    {
        return item.Preco * _fatorAjuste;
    }
}

GeradorPedido.cs

class GeradorPedido : IGeradorPedido
{
    private IPrecificador _precificador;

    public GeradorPedido(IPrecificador precificador)
    {
        _precificador = precificador;
    }

    public string Processar(Pedido novoPedido)
    {
        decimal total = 0;

        foreach (var item in novoPedido.Itens)
        {
            total += _precificador.CalcularPreco(item);
        }

        //Faz mais algumas operações com pedido

        //Número do pedido
        return "ABC123";
    }
}

Até aqui, tudo OK, certo? Ai entra um novo requisito e com ele aparece o problema...

Novo Requisito

Alguém decidiu que o fator dos preços deveria variar de acordo com a loja em que o pedido estava sendo feito. Se isso é uma regra de preço, a qual classe pertence? Precificador!

Quais opções temos pra implementar isso com o mínimo de impacto possível no sistema (já que a interface IPrecificador já estava sendo usada) e de maneira que a coesão e desacoplamento seja mantido?

Opção 1 - Adicionar um paramêtro no método CalcularPreco

A primeira opção que me veio a cabeça foi adicionar o paramêtro com a loja diretamente no método CalcularPreco da interface IPrecificador.

IPrecificador.cs

class Precificador : IPrecificador
{
    private decimal _fatorAjuste;

    public decimal CalcularPreco(ItemPedido item, Loja vendaEfetuadaEm)
    {
        if (vendaEfetuadaEm == Lojas.LojaUm)
            _fatorAjuste = 10m;
        else if (vendaEfetuadaEm == Lojas.LojaDois)
            _fatorAjuste = 15.4m;
        else
            _fatorAjuste = 0.9m;

        return item.Preco * _fatorAjuste;
    }
}

Parecia uma boa saída, mas depois de pensar alguns minutos encontrei dois side-effects graves que me fizeram mudar de idéia:

O novo paramêtro, Loja, passaria também a virar uma dependência direta pra todos que consumissem a interface IPrecificador já que estes [consumidores] seriam responsáveis por repassar a loja para poder realizar a chamada a CalcularPreco. Com isso estariamos violando o SRP adicionando um motivo a mais pra classe GeradorPedido e outras mudarem.
Diversos testes seriam quebrados pela adição do novo paramêtro, indicando que talvez não fosse a melhor alternativa já que essa alteração deveria afetar apenas uma classe

Opção 2 - Adicionar este paramêtro ao construtor da classe Precificador e utilizar uma Factory

Já que esta alteração diz respeito apenas a responsabilidade da classe Precificador, que tal adicionar este paramêtro ao construtor da classe? Ótima idéia, não?

De fato foi a solução que fez mais sentido já que necessariamente para chegar ao fator de preço a ser aplicado a classe precisa saber com qual loja estamos lidando. Para implementar, bastaria fornecer a loja via construtor e armazenar o valor em um membro privado da classe pra uso posterior. Dessa forma, todos os consumidores dessa classe iriam receber uma instância de IPrecificador já configurada e pronta pra uso sem a necessidade de se preocupar em fornecer a loja.

Nosso novo Precificador.cs ficaria assim:

class Precificador : IPrecificador
{
    private decimal _fatorAjuste;

    public Precificador(Loja vendaEfetuadaEm)
    {
        if (vendaEfetuadaEm == Lojas.LojaUm)
            _fatorAjuste = 10m;
        else if (vendaEfetuadaEm == Lojas.LojaDois)
            _fatorAjuste = 15.4m;
        else
            _fatorAjuste = 0.9m;
    }

    public decimal CalcularPreco(ItemPedido item)
    {
        return item.Preco * _fatorAjuste;
    }
}

No entanto, na hora que fui implementar esta solução esbarrei no meu container de DI, até então o Ninject, que resolvia a dependência de IPrecificador pra mim automaticamente sempre que necessário. Contudo, pra esta implementação eu precisaria fornecer um valor (a Loja) que só podia ser obtido em runtime na hora de construir a instância de IPrecificador.

Então a solução seria utilizar uma Factory!

GeradorPedidoFactory.cs

class GeradorPedidoFactory
{
    public static IGeradorPedido Criar(Loja vendaEfetuadaEm)
    {
        IPrecificador precificador = new Precificador(vendaEfetuadaEm);
        return new GeradorPedido(precificador);
    }
}

Mas trinta segundos depois descartei essa idéia porque IPrecificador estava sendo usado por outras classes além de GeradorPedido então eu teria que criar uma factory pra cada uma das classes que fosse consumidora de IPrecificador. Também dessa forma eu estaria anulando meu Container de DI espalhando a criação de tipos concretos por diversas factories ao invés de centralizar em apenas um ponto.

Opção 3 – Manter o construtor e utilizar uma Abstract Factory pra criar IPrecificador

A terceira e ultima opção antes da solução final foi utilizar uma Abstract Factory, que seria injetada via DI em todo mundo que precisasse de IPrecificador eliminando a necessidade de uma factory pra cada construtor e mantendo a responsabilidade no lugar adequado. Algo assim:

PrecificadorFactory.cs

class PrecificadorFactory : IPrecificadorFactory
{
    public IPrecificador Criar(Loja vendaEfetuadaEm)
    {
        return new Precificador(vendaEfetuadaEm);
    }
}

MyModule.cs

public class MyModule : NinjectModule
{
    public override void Load()
    {
        Bind<IPrecificadorFactory>().To<PrecificadorFactory>();
        Bind<IGeradorPedido>().To<GeradorPedido>();
    }
}

GeradorPedido.cs

class GeradorPedido : IGeradorPedido
{
    private IPrecificadorFactory _precificadorFactory;

    public GeradorPedido(IPrecificadorFactory precificadorFactory)
    {
        _precificadorFactory = precificadorFactory;
    }

    public string Processar(Pedido novoPedido, Loja vendaEfetuadaEm)
    {
        IPrecificador precificador = _precificadorFactory.Criar(vendaEfetuadaEm);
        decimal total = 0;

        foreach (var item in novoPedido.Itens)
        {
            total += precificador.CalcularPreco(item);
        }

        //Faz mais algumas operações com pedido

        //Número do pedido
        return "ABC123";
    }
}

Contudo, na hora que implementei pra ver como ficaria, percebi que tinha o mesmo problema da primeira solução: todo mundo que precisasse consumir IPrecificador teria que receber o paramêtro informando a Loja onde a venda foi efetuada para repassar para a abstract factory de IPrecificador a fim de criar uma instância concreta da classe. A dependência tinha voltado, apesar de a responsabilidade estar um pouco melhor distribuida. :(

A Solução Final

Quando eu já estava quase desistindo de procurar outra alternativa (mais uma) o @pedroreys deu uma idéia excelente: fornecer previamente ao container de DI a instância de IPrecificador que deveria ser usada quando ela fosse necessária.

Na hora fui atrás de como fazer isso com o Ninject que, era meu container até então. Infelizmente ele não implementa essa funcionalidade especifíca. Pelo menos não da maneira que eu gostaria [1].

Foi ai que decidi mudar para o StructureMap, container utilizado no exemplo do @pedroreys. O StructureMap, apesar de ter sido um dos primeiros containers de DI/IoC lançados (e de ser um pouco verboso demais pro meu gosto), se mantém atualizado e com uma excelente interface fluente exatamente como o Ninject.

A troca foi simples já que eu utilizo um Wrapper (omitido por breviedade) pro Ninject e a aplicação não tem contato com o container em si. O resultado acabou sendo um Mix de todas as soluções:

PrecificadorFactory.cs

class PrecificadorFactory
{
    public static IPrecificador Criar(Loja vendaEfetuadaEm)
    {
        return new Precificador(vendaEfetuadaEm);
    }
}

UnitTest1.cs

[TestMethod]
public void consegue_resolver_GeradorPedido()
{
    Loja vendaEfetuadaEm = RecuperarLojaOndeVendaFoiEfetuada();

    IPrecificador precificador = PrecificadorFactory.Criar(vendaEfetuadaEm);

    Container container = new Container();

    IGeradorPedido geradorPedido = container.With<IPrecificador>(precificador).GetInstance<IGeradorPedido>();

    Assert.IsNotNull(geradorPedido);
}

Dessa forma consigo:

Criar a instância de IPrecificador separadamente
Dizer ao container que quero que esta instância especifica seja usada somente nesta resolução de IGeradorPedido
Manter cada classe com sua responsabilidade

Any thoughts o this?

[1] – O Ninject, na última versão (2.0), implementa o método Rebind() que permite trocar o bind de uma interface em runtime. No entanto, esta troca é permanente e afeta todos os consumidores do container (Singleton, no meu caso) e no meu contexto, não faz muito sentido.

A caminho do Zen

2010-04-18T22:24:33+00:00

Hoje temos a nossa disposição milhares de fontes de informação e algumas dezenas de grandes agregadores de informação (rss, twitter, etc) que multiplicam a quantidade de informação a que somos expostos diariamente.

Agora, o desafio não é encontrar a informação, mas sim escolher qual informação iremos consumir. Até pouco tempo atrás quantidade significava qualidade, mas isso já não é mais verdade e a maioria das pessoas está tentando diminuir a quantidade de coisas que faz e a quantidade de informação a que é exposta. Menos virou mais.

Diariamente, incluindo RSS, Twitter, DNA e os links gerados a partir destes agregadores (que são os que mais uso) acho que gasto umas quatro horas lendo. Isso sem contar a pilha de livros que compro mensalmente e que vai se acumulando para leitura posterior.

Por conta disso, acabo não tendo tempo de executar os projetos que gostaria, entre eles escrever mais neste blog. Ler é excelente, mas a rede da web faz com que cada link aberto gere mais outros 200 e não conseguimos processar tudo ao mesmo tempo. Por isso, foco é fundamental.

Nos últimos dias defini uma lista de projetos/items que quero concluir nas próximas semanas. Sendo assim, vou tentar reduzir minha exposição à toda essa informação pra dar uma "desintoxicada" e focar nestes itens.

Estou compartilhando essa dificuldade por dois motivos: 1) Tornar um problema público faz com que a gente se mexa pra resolve-lo, afinal ninguém gosta de ter seus problemas expostos (ainda mais sem resolve-los, né?) e 2) Ver se alguém compartilha do mesmo "problema" e entender como cada um lida com isso, portanto você que está lendo isso, saia do read-only mode e comente este post! :)

Você é importante?

2010-03-02T23:50:51+00:00

Reza a lenda[1] que, trabalhando na Apple, a qualquer momento você pode encontrar Steve Jobs e ouvir dele a seguinte pergunta: "O que você faz aqui?" e, caso ele não goste da resposta você pode ser demitido na hora.

Apesar de essa ser uma atitude drástica, acho que faz bastante sentido, principalmente no cenário de desenvolvimento de software. Alguma vez você já se perguntou o que realmente faz na empresa onde trabalha? Se a resposta for tão simples como "escrevo código" talvez você esteja prestes a ser (merecidamente) ~~demitido~~ promovido ao mercado de trabalho . Mesmo como programador seu trabalho não é apenas escrever código, mas sim transformar idéias em maravilhas tecnológicas que vão fazer seu usuário delirar e com isso agregar valor para a empresa ou qualquer outra coisa que o valha. Isso vale para todas as posições.

Desde gerentes (que tradicionalmente só controlam cronogramas, ou seja, fazem nada) até gerentes de produto que ficam pra cima e pra baixo mandando as pessoas fazerem coisas. O ponto é, se você não contribui para o produto final você é inútil, totalmente dispensável e deveria arrumar uma outra coisa pra fazer. Sua contribuição não precisa ser necessariamente técnica (com código), mas também com soft skills (organização, segurança, criatividade, etc) que ajudem efetivamente seu time a chegar ao objetivo.

Acho que esse é um ponto importante de reflexão. Para sermos melhores no que fazemos temos que entender realmente o que queremos e temos de fazer.

O que você acha?

[1] - Segundo relatos existentes de (ex) funcionários no livro "A cabeça de Steve Jobs"

Cuidado com os especialistas!

2010-02-23T23:42:30+00:00

Hoje em dia com toda essa modernidade (como diria minha vovó) e a facilidade na disseminação da informação que a internet nos trouxe surgem a cada dia mais e mais especialistas. Em cada esquina da internet é possível encontrar um. Não importa o assunto.

O cara começa com um blog ou um grupo de discussão, manda bastante tweets, adiciona uma pitada de promoção pessoal em todo canto, dai avança pra meia dúzia de palestras e até se propõe a ministrar um curso sobre o assunto. De repente, em poucos tempo virou especialista E referência no assunto!

Vendo tanta propaganda você deve achar que o cara tem muita experiência e é uma ótima fonte de informação. Boa fonte de informação pode até ser, mas repetir tudo que ve como um papagaio é ser um especialista? Ministrar cursos e posar de conhecedor do assunto apenas com conhecimento teórico é suficiente? É ético?

Será que é essa mesmo a definição de especialista que procuramos? Ainda mais sobre assuntos não técnicos ou soft-skills onde toda a bagagem e experiência que podemos conferir é escrita/falada? São essas nossas referências?

Tenha cuidado quando alguém lhe apresentar o título de "Especialista em XYZ". Papel e meios de comunicação similares aceitam qualquer coisa, já dizia minha professora na quina série.

Infelizmente não há maneiras práticas e fáceis de reconhecer falsos especialistas. O único jeito é desconfiar sempre e não disseminar informações baseadas na falácia da autoridade. Seus amigos, seu chefe e seu bolso agradecem!

Lidando melhor com WCF - Ciclo de vida no cliente

2010-02-23T14:02:31+00:00

<Importante>

Todos sabem que WCF é uma plataforma poderosa e extensível. O que muita gente não sabe é que WCF é para poucos.

WCF é uma plataforma que permite a construção de sistemas distribuidos e sistemas distribuidos raramente são necessários. De maneira simplificada, podemos dizer que um sistema é distribuido quando tem seus componentes instalados em mais de um computador.

O problema da construção de sistemas distribuídos é que devido a não centralização de seus compnentes existe um overhead de comunicação entre os computadores e serialização/deserialização de objetos e isso consome muita memória e banda de rede.

Como gastamos mais recursos do que necessário temos como resultado final um aumento no tempo de resposta e gasto extra de hardware que, as vezes pode ser um problema grave além é claro do aumento da complexidade técnica.

No entanto, não sei por qual motivo, no momento em que lançou o produto, a Microsoft esqueceu de avisar seus "consumidores" a respeito destes pequenos detalhes. Talvez porque queria promover o produto?

</Importante>

<Importante 2>

WCF é uma tecnologia relativamente simples, mas apenas depois que você entende o BeABá da coisa (ou ABC[1] no caso do WCF). Até lá, qualquer coisa que fuja do point&click que o Visual Studio nos oferece é relativamente complexo.

Portanto, sugiro que antes de aplicar WCF você procure entender um pouco mais dos fundamentos e do papel de cada objeto que ele utiliza.

</Importante 2>

Agora que entendemos que não devemos usar WCF em toda aplicação que construimos (talvez isso seja tópico pra outro post?) vou falar um pouco da experiência que estou tendo com esta tecnologia e das boas práticas e atalhos que conheci.

Pretendo fazer uma pequena série e pra começar vou abordar boas práticas de consumo de serviços WCF, ou em outras palavras, como acessar um serviço WCF a partir de um cliente da maneira mais eficiente possível.

Para que seja possível consumir um serviço WCF é necessário que alguém o tenha publicado e também que tenha disponibilizado o WSDL[2] do serviço.

O WSDL nada mais é do que um arquivo XML que descreve quais são os tipos de dados que o serviço irá trafegar e quais operações ele oferece.

Geralmente, assim que temos um WSDL para consumir vamos ao Visual Studio e utilizamos a funcionalidade de Add Service Reference que ele nos oferece para gerar o objeto proxy que irá cuidar pra nós da comunicação com WCF. A partir dai utilizamos este objeto em toda nossa aplicação__. E este é o nosso maior erro.

Este proxy, gerado pelo Wizard, encapsula todas as classes necessárias para ler o WSDL, criar os tipos necessários e lidar com os canais de comunicação em cada operação que executamos. No entanto, ele o faz da pior maneira possível.

Cada vez que invocamos uma operação através deste proxy, ele cria uma instância da classe ChannelFactory<T>. Esta classe é responsável por ler as configurações definidas em nosso app.config e baseado nestas configurações abrir os canais de comunicação com o serviço que iremos consumir. Este processo é muito lento, pois todos os sockets, listeners e objetos necessários da própria infra estrutura do WCF são criados e configurados neste momento.

No entanto, este processo não precisa ser feito a cada chamada para o serviço WCF uma vez que estas informações não mudarão enquanto a aplicação estiver rodando. Então, para otimizar bastante o consumo de serviços devemos ignorar o proxy gerado pelo Wizard e cuidar da criação e destruição de canais nós mesmos mantendo este objeto (ChannelFactory<T>) como Singleton que irá durar pelo tempo de vida da aplicação. Dessa forma toda vez que chamamos uma operação remota não existe a necessidade de executar o setup e tear down desse objeto.

Para facilitar a gerência desses objetos construi uma pequena DLL que é composta apenas de uma classe. O código está disponível no github e a DLL compilada está aqui. A documentação inicial também está lá. Tudo pronto para ser usado.

Referências adicionais (e importantes)

[1] ABC = Address, Bindings e Contracts
[2] É possível consumir um serviço WCF sem acesso ao WSDL, mas este é um cenário pouco comum

[Off-Topic] Problemas com monitor Samsung e exemplo de péssimo atendimento

2010-02-13T09:32:58+00:00

Não costumo fazer esse tipo de off-topic, mas essa situação me revolta simplesmente pelo fato de não poder fazer nada além de reclamar e "chorar" por ai.

Em dezembro de 2007 adquiri um monitor Samsung 2232BW pelo valor de R$1027,00. Até onde eu sei esse valor não é baixo e tem gente que não ganha isso em um ano inteiro de trabalho.

Pouco mais de 2 anos passados, mês passado ele começou a apresentar um problema com seu painel. Isso já me deixou p*** da vida, pois 2 anos de vida útil em um produto deste valor é rídiculo. Meu CRT 17 nunca deu um problema em quase 5 anos que ficou em uso.

Como um monitor equivalente hoje custa na faixa de R$500, decidi que valeria a pena tentar levar meu monitor para conserto e caso o custo do serviço ficasse em até R$200,00 acredito que compensaria.

Procurei no site da Samsung as assistências técnicas autorizadas, que apesar de serem terceirizadas, levam o nome Samsung e deveriam responder com o mesmo padrão de qualidade que a Samsung vende em seus produtos e encontrei 3 em um ráio de 20km da minha casa. Fui as três e realmente conclui que elas atendem seguinde o mesmo padrão inexistente de qualidade da Samsung com filas de mais de uma hora e meia apenas para ser atendido na recepção pra tentar descobrir se é possível o conserto e qual seria o valor.

Conclusão: é mais fácil ser atendido no poupa tempo ou em um posto do INSS do que em um serviço autorizado da Samsung que iria receber pelo atendimento.

Obrigado Samsung pelos momentos de frustração e pela demonstração de como operar um negócio onde o cliente claramente não tem importância nenhuma além, é claro, de me colocar em uma posição onde eu tenha que implorar para ter meu monitor consertado!

Qual é a dos apertadores de botões?

2010-01-29T13:19:52+00:00

Não importa onde eu vá, seja a empresa grande ou pequena, sempre existem pessoas dos dois grupos: apertadores de botões e as pessoas que vão pra frente.

As pessoas que vão pra frente são fáceis de identificar e não me interessa falar muito sobre elas neste post. Elas estão sempre empolgadas, comentam a respeito de novidades e procuram fazer ela e as pessoas em sua volta prosperarem, mesmo quando essa não é a intenção.

Já os apertadores de botão estão sempre na mesma. O incrível é que esse perfil (ou falta de perfil?) existe em todos os papéis e profissões. DBAs -que só rodam scripts e não analisam o log (nem quando solicitado!) pra ver o que aconteceu e ajudar o pobre desenvolvedor que não tem acesso ao DB-, Desenvolvedores -que programam o que está especificado não importando o quão errado esteja do ponto de vista técnico ou funcional-, entre muitos outros.

No entanto, podemos ainda criar outra categoria de apertadores de botões: os que fazem apenas tarefas repetitivas. Quem nunca viu o "operador de computador" (acho que essa expressão é do mesmo tempo CPD) que todo dia, o dia inteiro, fica copiando/alterando arquivos de lá pra cá, sempre igual?

Por mais que eu não goste do meu trabalho (ainda bem que eu gosto!), acredito que devemos tirar o melhor proveito dele. Ou melhor, devemos tirar o melhor proveito de tudo que fazemos na vida. Portanto, o que motiva uma pessoa a executar o mesmo processo igual todo dia sem nem mesmo pensar em uma maneira de automatizá-lo ou de faze-lo de maneira diferente?

Mesmo que você não consiga remover todos os processos repetitivos ou não crie uma obra de arte quando conseguir é importante tentar. Não importa se você vai ser reconhecido por isso, não importa se você irá ganhar $algo$ em troca e não importa se você não é pago pra automatizar nada. Faça por você! Mesmo quando o esforço não valer a pena você vai no mínimo ter aprendido alguma coisa nova.

Portanto, se você se encaixa em algum desses perfis, já passou da hora de se mexer e mudar, não acha?

Reunião .NET Architects em 16/01/2010 - Referências

2010-01-17T15:09:52+00:00

Ontem durante a reunião do nosso grupo de discussão de .NET o Fabio Galuppo falou sobre um pouco sobre F#. A apresentação foi muito boa e logo após, durante a "mesa redonda", eu mencionei uma série de aulas gravadas na Universidade de Berkeley sobre o assunto Linguagens Funcionais. É o curso completo gravado. Como o pessoal se interessou e pediu os links ai vai:

Primeira aula do curso - As demais podem ser encontradas nos vídeos relacionados
Outros Cursos de Berkeley - Canal da universidade no YouTube com outras diversas aulas
Vídeos e WebCasts no site oficial da Faculdade - O primeiro link contém os vídeos disponibilizados no YouTube. No entanto, a faculdade também disponibiliza em seu site os mesmos vídeos além de outros da disciplina de ciências da computação.

Depois da reunião oficialmente terminada fomos almoçar e como acabamos entrando no assunto de gestão de projetos comentei um pouquinho a respeito de gestão democrática e prometi deixar alguns links disponíveis:

Palestra do Akita que foi uma das minhas maiores motivações sobre esse assunto
Palestra do Ricardo Semler no MIT - Essa é a palestra que o Akita cita como referência
Lvros de Autoria do Ricardo Semler no Amazon e no Submarino
Manager Without Managers - Paper da Harvard Business Review também de Autoria do Ricardo Semler sobre o assunto
Palestra do Akita @ RailsSummit 2009 - Essa é pra quem quiser viajar mais e conhecer as entradas que levam ao assunto de maneira mais profunda

Eu não uso Scrum porque Scrum não funciona!

2010-01-14T19:28:15+00:00

É Isso ai! Scrum não funciona!

Sabe porque Scrum não funciona? Porque se chama Scrum. Esse hoje é o maior problema do Scrum. Há dois anos atrás pouquíssimo se falava nisto que hoje virou hype. Nessa época as pessoas só falavam que usam Scrum depois de estudar bastante, trocar experiências e exercitar bastante. Ai sim alguém tinha coragem de dizer "Eu uso Scrum" e ainda assim com um pouco de receio, pois sabiam que tinha mais coisas além de apagar toda documentação do projeto e e quebrar as cadeiras pra fazer as reuniões em pé. As pessoas (a maioria) que diziam isso sabiam o que estavam dizendo. Scrum tinha credibilidade.

Nessa época, essas pessoas que conheciam agiram como evangelizadores do Scrum e finalmente ele atingiu as massas. No entanto, hoje o que mais se ouve são times/pessoas que não tem a menor idéia das noções e fundamentos por trás do Scrum ou qualquer outro processo/metodologia/framework ágil dizendo que são praticantes de Scrum. Até gente que nunca participou de um projeto usando Scrum hoje vende Scrum.

Isso é propaganda ruim. E propaganda ruim se multiplica muito mais rápido do que a boa. O pior da propaganda ruim é que cria-se ainda mais preconceito em cima de algo que já encontra resistência naturalmente. Isso tira todas as chances de sucesso de uma implementação de Scrum. Estou cansado de ver em todos os lugares pessoas frustradas dizendo que tentaram implantar Scrum em suas empresas e não conseguiram. Mas é claro que não! O filme do Scrum já está queimado. Você vai falhar antes mesmo de tentar.

Já faz um tempo que eu parei de vender a idéia de usar Scrum. Desde então eu digo que eu procuro executar práticas ágeis. Soa mais leve, mais simples. O pré-conceito diminui dessa forma e a resistência também. Do que importa se meu facilitador chama Gerente de Projetos ou Scrum Master? As pessoas se preocupam mais com nomes do que com resultados e esse é o problema. Agilidade é o que há, mas funciona melhor sem rótulos.

Verbos HTTP: GET e POST. Você sabe mesmo a diferença?

2009-11-22T21:23:51+00:00

Até pouco tempo atrás quando eu fazia entrevistas a fim de contratar desenvolvedores, não importando o nível, eu fazia a mesma pergunta: "Você sabe a diferença entre GET e POST em uma request HTTP?". Por incrível que pareça poucas pessoas sabiam responder. Na maioria das vezes alguém que se considerava um desenvolvedor web não tinha a menor idéia sobre o que eu estava falando. Acho que era culpa do RH que fazia uma pré-seleção muito ruim, mas anyway...

Hoje essa informação já chegou a maioria dos desenvolvedores web (já era hora, não?) então a pergunta no contexto original perdeu um pouco a validade. Todo mundo sabe que enviar formulários via GET manda as informações pela querystring e que POST manda encapsulado dentro da request e bla bla bla. No entanto, com a nova "moda", que acho bem bacana aliás, de REST(ful) a pergunta ganhou um contexto novo e tornou a ser válida: você sabe qual a diferença dos verbos em uma request HTTP? Não só de GET e POST, mas de todo o resto?

Decidi fazer esse post rápido enquanto retomava meus estudos a respeito de WCF e assistia a um vídeo do MIX do ano passado que está no final deste post.

POST não escala, GET sim. Porquê? Por causa da semântica! POST, PUT, DELETE e outros verbos são por definição non-safe e com efeitos colaterais, ou seja, é esperado que uma request usando esses verbos modifique algum recurso. Dessa forma é impossível fazer cache desse tipo de chamada. E como todos nós sabemos, sem cache = sem escalabilidade, isn't that right?

Vamos tomar como exemplo uma chamada a URI imaginária: http://meusite.com.br/usuario/novo passando via POST todas as informações necessárias para se criar um usuário. Se tudo correr bem, vamos receber como resposta um HTTP Status Code 201 indicando que o recurso foi criado e a URL para acessa-lo. Provavelmente algo como http://meusite.com.br/usuário/765.

Agora a pergunta: é seguro para os intermediários dessa request tais como proxies, clientes, etc efetuarem o cache disso? Não! Imagine um usuário do sistema que utiliza esse recurso tentando cadastrar um novo usuário com os mesmos dados. Ao invés de receber uma resposta de conflito ele receberia um status 201 dizendo que o recurso foi criado. De fato o recurso foi criado, mas será que deveriamos mostrar isso pra ele quando na verdade a criação desse recurso já havia acontecido e a ação que ele executou neste momento não trouxe sucesso? Acho que não.

Já o GET, por definição é cacheavel, pois não possui efeitos colaterais. Ele apenas devolve o recurso desejado sem modificar nada. Claro que isso só acontece quando bem usado, pois tem muita gente que utiliza esse verbo de maneira errada e baseado em parâmetros executa ações que deveriam ser associadas a outros verbos HTTP. Como não modifica nenhuma informação é possível efetuar o cache desse recurso com segurança.

Pra quem quiser ver mais a respeito de REST, GET, POST e cache, basta acessar o vídeo no site do MIX 09.

De volta a terrinha

2009-10-29T11:41:38+00:00

Acho que todo mundo já sabe, mas para aqueles que não sabem ainda voltei ao Brasil no mês passado. A idéia era ir para os EUA e ficar por lá, mas como nem tudo na vida são rosas tive uns problemas familiares por aqui que fizeram com que voltasse. A idéia de me mudar daqui ainda é muito forte e vai acontecer. Só teve de ser postergada um pouquinho :)

Apesar de voltar pro Brasil continuo trabalhando pra HNI, mas de maneira remota, o que não deixa de ser uma experiência bem interessante dada a diferença de timezone e dificuldade de comunicação.

Isso quer dizer que vou voltar a postar bastante no blog como eu fazia antes? Espero que sim, mas agora vou fazer um pouco diferente e gostaria de um feedback de quem lê pra ver se estou agradando ou não. A idéia do blog foi sempre postar coisas que eu acho interessante e conheço, mas com alguma experiência prática e opinião pessoal no assunto. Isso faz com que os posts saiam relativamente grandes e demorem muito para serem escritos (da trabalho, mesmo que o resultado final não seja o melhor do mundo! eheheh).

Por conta dos problemas do dia a dia e da natureza do meu atual trabalho posts assim vão ficar um pouco mais raros, mas quero aumentar sua frequência em breve. Enquanto isso, vou compartilhar informações mais curtas, comentários menores e links que acho que valham a pena divulgar.

Além disso, também estou fazendo uns tweaks no blog e um deles que já pode ser visto é o de idiomas. Quando acessarem o blog pela próxima vez via HTTP o plugin vai identificar sua origem e direcionar para os posts na lingua correspondente: inglês ou português. As duas línguas vão ficar disponíveis, mas será necessário clicar no post de outro idioma para le-lo.

O endereço direto para os posts em inglês é: http://blog.tucaz.net/en e para os posts em português é: http://blog.tucaz.net/br.

Dessa maneira contínuo escrevendo em inglês e praticando o idioma e posso escrever também em portugûes conteúdo que acho que valha a pena apenas para nós brasileiros (como é o caso do próximo post que está na fila).

Ainda não sei exatamente como os feeds vão se comportar, mas vamos descobrir em breve. :)

Por último, caso encontrem problemas com o feed ou com o blog ou tenham comentários ou perguntas de qualquer natureza, POR FAVOR me avisem pra eu melhorar/resolver o que for necessário. Okidoki?

SoçarbaI guess everybody already knows, but for those who don't: I'm back to Brazil. The initial idea was to move to USA for good, but unfortunately some family matters came to show up here and I had to come back. The idea still lives and it's gonna happen, but not so soon now. I'm still working for HNI, remotely though. However, It's still a great and new experience due to timezone differences and communications problems. A lot of opportunities to learn from.

Because of that, I think I won't be able to write long posts as I use to do before. Posts like that, mainly related to people and management ideas, are hard to write and take a lot of time. In this case I'm going to write smaller posts with personal opinion regarding the subjects I like and share useful information about mixed subjects without deeper thoughts. At least for now.

Another thing I wanted to say is that I'm working on some blog tweaks and you already going to see a new one: multiple language plugin. Based on the HTTP request the plugin is going to identify which language should be shown to the user: English or Portuguese. I did that because I still want to write in English to reach more people and to practice the language, but there are some content that are only relevant for Brazilian people who on the majority only understands Portuguese and I want to reach these people too.

All posts are still available to both languages but you will need to click on those that are not you're native language in order to ream them. The home URL of the blog is going to make the distinction between the languages but if you want to choose yourself you can access http://blog.tucaz.net/en for English content and http://blog.tucaz.net/br for Portuguese.

So, to end this post, I want to ask you to report any errors or problems with the blog itself or with the feed (I still don't know how it's going to behave with this new plugin) and say that any questions, suggestions and complaints are more than welcome. Feel free to contact me anytime :)

(Inglês) [Book Review] Startup

2009-10-02T18:22:11+00:00

It's been a while since my last post. I was in USA at the time. Now I'm Brazil again. A lot of things have changed, but I will (hopefully) write about it on another entry.

Right now I want to write about a book that was on my reading queue for a while: Startup by Jessica Livingston. I got this book last weekend and, truth to be told, I am a little bit frustrated with it.

Before I bought it I expected to see great insights about starting a new company, making it develop and grow. But this wasn't what I got. The book follows the format of a series of interviews made with founders and co-founders of big and important companies of our time where they explain a little bit about how they started, but without any deep thoughts. Companies like Apple, Hotmail, Yahoo!, Firefox and other.

So, after some moments of frustration I changed my mindset and could actually enjoy the reading. I stopped thinking about getting good insights from it and started to read it to understand how American startups worked, subject that I had a vague idea about. Now I have a little bit more information about it and it goes like this:

Most American startup companies are created in college/university. Great and brilliant students get together and talk about a really nice idea. You can almost think that they can predict the future because they changed the way we use computers today, but they don't. They actually make the future happen the way they wanted. Almost always, after discussing and prototyping a bit they come up with a business plan and with this very important piece of paper in hands they go after investors. Venture capital investors. People who want to risk their money in things that might work in exchange of a piece of the company. Making a long story short, after a lot of work and effort they sell (or not) their companies for billions, pay back the investors and sometimes keep working for the company as an ordinary employee.

Getting back to the book and startups formation, the first thing you will notice is the fact that opening a startup company has nothing to do with Brazilian reality. It won't work here the same way it does in USA. Not even close. It's all about culture and infrastructure.

In USA you can find good universities (they are expensive, but also good) that teaches you a lot of new things and the basics about everything you need to know to work with computers (or whatever subject that you are studying). But we also have good universities, right? Yes we do, but the problem is that only a minor portion of our students have their studies paid by their parents, like they do. In Brazil we have to work our way through college/university and think about bringing money to our home and families. We have to worry about making a living. In my opinion this is the big difference: investment in education. We could use some of that here.

While in college, American students don't have to worry about anything else other than studying. The structure offered by the government and their families makes students prosper. They have the knowledge in their hands, the supplies and tools needed to transform the knowledge into something tangible and in the end a culture of investment that makes it possible to raise large amounts of money needed to start a company and keep it breathing. We have all this guts too, but unfortunately we don't have the culture and the investments necessary to make it work.

Of course we cannot take away all the quality and merit that they deserve. They have great ideas and guide our IT world. But, I would say that this only happens because they have a more fertile environment (government quality, economics, security, etc) than we do.

It doesn't mean that we can't do something like that. It only means that is harder here. Thanks to our interest rates, taxes and politics. We can see that this is true by counting the number of startups in Brazil and how many companies survives after five years that they are open. I don't think I can fill my hand's fingers couting it. Can you?

Although it's not a must read book I would say that is a good reading that can help you understand a little bit more about the foundations of the companies that currently rule our world when it comes to IT.

Hope you enjoy!

ps: Even though I was in USA for three months and studied a lot of English it still needs improvement and because of that you will find some errors in the text. If you want to help, please leave a comment when you find one. Thanks! :)

(Inglês) Basic stuff: handling exceptions in .NET

2009-07-21T13:19:09+00:00

Last week we had a severe problem with exception handling in a project I'm working in. All the exceptions were being suppressed so we couldn't know what was going on when some functionality didn't work as we expected it to. This happened because a member of our team misinterpreted exception handling and put try/catch blocks in every method that he coded, but didn't put any code in the catch block.

The code spreaded everywhere looked like this:

try
{
     //Aplication logic goes here
}
catch (Exception ex)
{
     string error = ex.Message;
     //No re-throw or any exception handling code. Just this.
}

As soon as we discovered the problem (and who was causing it), Max (a co-worker) wrote this "guide" and we made sure that everybody involved in the project read it. This is pretty basic stuff, but lot's of people still don't understand it. I'll reproduce it below "as is" hoping that it will help you or someone you know :)

What is the problem? Whenever an expection is trown, the code is trapping it in the catch block and it’s basically destroying it without proper handling and without escalete it in the stack (exception bubbling).

Why is it a problem? This results in one of the worst maintenance nightmares. As the exception is being destroyed before it can be captured, bugs will become almost impossible to track in an QA/Production environment where debug is not available. Even in the development environment, chances are you’re only going to be able to track the root cause stepping through the code line by line.

What to do? Unless you really have a need to do something specific with an exception, just let it escalete through the stack. Exceptions are usually handled at a higher level (like the user interface). Even when you need to do something with the exception, it will usally be necessary to re-throw it at the end of your code uless you’re coding the last layer (like a UI).

Here are some good practice examples:

Example 1:

public string GetUser(string userName)
{
    return new DAL().GetUser(userName);
}

In this example the GetUser represents a intemediate layer code. As we don’t need any special handling, any exceptions resulting from the DAL method call will be simply escalted to the caller through the exception bubbling.

Example 2:

public string GetUser(string userName)
{
    try
    {
        return new DAL().GetUser(userName);
    }
    catch (Exception ex)
    {
        LogHelper.LogException(ex);
        throw;
    }
}

In this case we do need to do something special about the exception. A good example would be a web service, where we should be loggin any errors, but re-throwing it to the caller so the application will be aware of it.

Example 3:

bool isValid = false;
try
{
    //Your application logic goes here
    isValid = true;
}
catch (DivideByZeroException)
{
    //Nothing needs to be done in case of an exception, this will kee the flag isValid as false
}

This example illustrates a situation where you really need to destroy the exception. The Try/Catch block is being used exclusively to set a flag that depends on the result of an operation that might throw an exception, which would mean the status is invalid. Please note three important things:

a) In this case it is fundamental to add a comment to the Catch block in order to let your intention clear.

b) As you’re not planning to do anything special with the exception, a “catch(DivideByZeroException)” syntax is enough, since you won’t need to assign the exception to a local variable (which would generate a compilation warning about an unused variable). e.g.: catch (DivideByZeroException ex).

c) In this type of scenario you’re looking for a specific exception, so make sure you’re catching only that specific type of exception and let anything else bubble up (meaning, do not use “catch { }”). Also, when catching a specific exception, there’s no need for adding extra catch for the generic exception, anything else will automatically bubble up:

catch (DivideByZeroException)
{
    //Nothing needs to be done in case of an exception, this will kee the flag isValid as false
}
catch //There’s no need for this block
{
    throw;
}

Issue: You re-throw the exception using the “throw Exception” syntax:

What is the problem? This resets the exception stack trace.

Why is it a problem? The stack trace is lost and higher levels will perceive the error as being generated by your code. The main issue is the fact that it won’t allow you to track the root cause of the exception.

What to do? The correct syntax to re-throw an exception is to simple state “throw” in your code, this way the stack trace is preserved.

try
{
    //Application logic goes here
}
catch (Exception ex)
{
    LogHelper.LogException(ex);
    throw;
}

What if you need to generate a custom exception? Same issue with the stack trace. In this case the Exception constructor provides a parameter for the inner exception that must be used:

try
{
    //Application logic goes here
}
catch (Exception ex)
{
    LogHelper.LogException(ex);
    throw new Exception("My custom message", ex);
}

Issue: Unnecessary use of a Catch block when all you need is to get some code running at the Finally block:

try
{
    //Application logic goes here
}
catch
{
    throw;
}
finally
{
    //Your finally code goes here
}

What is the problem? The catch block in this case is completely unecessary.

Why is it a problem? Not a big deal, but it represents unecessary lines of code that will make your code look dumb to your collegues.

What to do? Just use a Try/Finally block:

try
{
    //Your application logic goes here
}
finally
{
    //Your finally code goes here
}

ps: methods used in the examples are using an anemic model for simplicity purposes.

(Inglês) Leading by omission

2009-07-13T10:08:42+00:00

Yesterday I was watching a great screencast made by Akita On Rails about agile software development and the future of software organizations and at some point he mentioned a speech named "Leading by Omission" that Ricardo Semler, CEO of Semco, gave some time ago at MIT about nonexistence of hierarchical chain of command at Semco and how it works for them. With that kind of management system Ricardo was able to drag Semco out the down path twenty five years ago and turned his company into one of the most successful companies in their field.

During the screencast, Akita also mentioned that, at Semco, the employees are responsible for defining their own salaries and they can choose who their boss is. This different way of working attracted my attention and made me search for Ricardo's speech.

I found it at MIT World website which also holds many other videos about almost all subjects you can think of, from science to religion. I only watched Ricardo's speech, but definitely other videos are on my queue now :)

The video is almost fifty minutes long and worth's every second of it. You can find it here

(Inglês) Communicating and understanding are the keys to succeed

2009-07-08T00:52:21+00:00

This is a very simple thought once you figure it out, but it appears that most team leaders and managers didn't figure it out yet. So, I'll write explicitly and hope that some of these people out there will read it here. :)

In order to achieve a goal through team work[1], the manager, or whoever is responsible for that, has to make his team understand three things: what exactly they are supposed to do, why they have to do it and what is the unacceptable result or, in other words, what they can't do.

It's really simple, but I only realized that this is an universal truth one year ago when my first agile attempt failed. After that, I spent a lot of time thinking why it went out that way. My first thought was that my team really sucked and because of that they were unable to do what I expected them to do. But after some time I realized that my team was very good technically and that the problem was my failure to properly communicate with them. I was unable to communicate them these three simple pieces of information.

Since that, every time I need to lead people, I try my best to make sure that they really understand what's going on. Because if they don't, the best result I can expect is that they'll follow my instructions as a monkey will do and, hopefully, I'll get the job done. I don't want that. I don't want to hope for something. I want to be sure that, at least, I'll have the best that these people can offer and don't have to review their stuff all the time to make sure they got it right.

In this whole last year, I gathered some thoughts from my experiences on how to communicate these simple pieces of information and here is what I came with:_ _

Explain how it's going down, present the context - Before any movement, present the general idea of the project[2] to everyone that's involved in it. Don't simply tell them which tasks they are supposed to execute. Understanding the context (technical, business and political) is very important.
Make sure they understood - Ask some questions, have them presenting some ideas and thoughts about the project. If they really understood it, they'll look excited (unless the project sucks!) and you will quickly notice they got it. This feeling of understanding will be presented to you as shinning eyes. That thing we all have when it rings a bell inside our head.
Tell them how/why it works - Talking specifically about software now, if we need someone to solve a problem by coding something we can't just tell them how a screen or a procedure should work and expect success. To achieve it we need to fully explain why that thing should be made in this or that way. By explaining how things work we get two main benefits: 1) The act of explaining is the best way to make sure we understand about the subject ourselves and 2) We can use other's knowledge and experience to make it work even better.
Show you trust them, share responsability and authority - Akita described it very well (it's in portuguese, sorry) in his blog post. It's vital that who is going to execute something has the authority to fulfill the responsibility he just received. You should trust and believe that the responsible person is going to execute it in the best way he can and give him all freedom he needs to do his job.
Make a plan - Planning is a very important thing. Not because of the final plan, but because of the act of planning itself. When you plan you have to think about the subject. You have to think how it can be done, what are the risks, what more should I know that I don't know, etc. Do it together, with all team members.
Also, give limit boundaries - Last tip, it's important to define some boundaries to everyone that is involved, borders that they can't cross. If for any reason they can't do something or you don't want them to do something you have to explicitly tell them no to do so. Otherwise there's no way they'll know it. And of course, you have to explain why they can't or shouldn't do it.

I believe that these five tips can increase the success chances in almost all scenarios we face everyday dealing with teamwork and I also hope that it will help you the next time you ask for something and get it different than you imagined.

[1] It doesn´t have to be a big team. I consider team work when more than one person is engaged in the same project to achieve the same goals.
[2] I'm using the same definition for project that David Allen does. Project is anything that needs at least two steps to be done.

(Inglês) Almost good!

2009-07-06T03:33:16+00:00

Hey!

It's been a while since I wrote my last post. That's because I was a little bored of writing. But now, I think I'm good to start it again. Did you miss me? :)

When I moved this blog from the old server I had some troubles during the change and I was too lazy to fix them, until today. I took a deep breath and made a fresh install of Wordpress. I still have to install some missing plugins, but I'm pretty confident that everything is going to work normally again.

I also changed the blog template (but I guess that you can see that, right?) and during the next few days I'll still be adjusting it to look better ( I don't know if it's possible for it to look good, but I liked it anyway).

So, from now on you can start waiting for regular updates again on this blog :).

By the way, I gave up on my Flickr because it really sucks. So if you want to see my pictures you can go to my Picasa Web. I hope you enjoy! :)

(Inglês) Blog Maintenance

2009-05-24T16:21:13+00:00

Today i'll be moving my blog from the current host. During this time it may be inaccessible due to DNS changes and it should take some time until new DNS are replicated. Sorry for the inconvenience.

See you soon!

(Inglês) We should fire more

2009-05-19T22:08:42+00:00

Before I get to the point in this post I should say that this is my first post in English and because of that I'm sure that it's going to have a lot of mistakes. Knowing that, I would like to ask you to correct me whenever you find one of them. Ok? Let's go!

I've been working as a professional developer since 2004. At that time I didn't really know anything about software development. Nowadays, almost six years later I still don't know much, but one thing I do know: only people can make a project succeed.

Since I started working I talked to many people from many different companies (clients and co-workers) and for a little bit more than two years i am in a position where i can choose if we should hire someone or fire someone. During this time I've heard almost nothing about people getting fired for being a bad professional. That's a strange behavior and made me think. Why don't I see many people being fire? I think I can count on my fingers how many times I saw someone getting kicked out from a company. If we pick my team as example I can tell you that we worked approximately with thirty different people in these years and I can only remember of letting one person go.

After gathering this personal experience, watching a lot of presentations and reading books and articles I realized that projects and products that were successful had one simple[1] thing in common: good people.

I think that the modern companies that are full of those "quality guaranteed" processes (ISO, CMM, ITIL and [put another silver bullet process in here]) forget how to make people perform good on their jobs. They put too much effort in the belief that the process is enough to keep things great and forget that people doing mediocre work are very bad for business.

By doing nothing to this people, we are encouraging who doesn't do a good job instead of congratulate who really does. If I stop and look backwards I'll see that i did that myself a lot of times. I saw someone on the team that was not up to his/her tasks and even seeing that I kept myself quiet. This is very harmful for everyone involved.

Another reason of why it happens is laziness. Managers and leaders often see that a team member is not corresponding well but they are too lazy and accommodated to do something about it. It's easier to let things just happen than change the situation and hire someone more skilled[2] to do the job.

I could seat here and write until sun shines again how a bad professional looks like, but I'm pretty sure you know how to recognize one. Everybody knows what a bad professional looks like, but still, they have jobs and they make my job (and yours, good one) more difficult.

So from now on, promise yourself that you're not just going to keep the wheels spinning. Propose changes, challenge people, force them to do their best. If after all this hard work you still have a bad team member, fire him/her and give his/her place to someone who deserves it. This is the only way we can build better teams and make bad professionals go away (or improve themselves).

[1] Yeah, it's pretty simple once you've figured that out.
[2] By skilled I meant technical and personal skills that are very necessary to make a person able to be part of a team.

Flickr!

2009-05-14T21:41:25+00:00

Não, esta ainda não é a volta dos meus posts técnicos. Essa semana estou me ajeitando aqui em BH então se tudo der certo volto a postar nesse fim de semana, ja que vou ter bastante tempo livre.

Enquanto isso, criei uma conta no Flickr pra colocar algumas fotinhas que for tirando. Check it out!

Novos ares

2009-04-30T18:11:45+00:00

As férias estão acabando, mas o tempo acabou não sendo 100% dedicado a descanso. Quem convive comigo sabe que a algum tempo eu estava participando de um processo interno da Stefanini para uma posição em um cliente nos EUA. Eu sempre trabalhei em consultorias e tinha vontade de trabalhar em uma "empresa de verdade" onde o core business não fosse TI, mas sim uma ferramenta de apoio onde os projetos tem continuidade e você pode ver o monstrinho crescer. Outra vontade sempre foi morar fora do país, principalmente onde a desigualdade e as possibilidades de levar uma vida mais justa fossem maiores. E este momento chegou, foi um processo longo e cansativo, mas durante esse período de férias o resultado saiu e eu tive que começar a mexer os pauzinhos para deixar o pais.

Isso mesmo. A partir da próxima semana não farei mais parte do time que ajudei a montar aqui em São Paulo. Irei para Belo Horizonte em outro escritório da Stefanini fazer um "estágio" com a equipe que atende a HNI Corp aqui do Brasil para na sequência, provalvemente no final de junho, me juntar ao time in-loco da HNI em Muscatine no Iowa.

A empresa onde vou trabalhar é uma das maiores fabricantes de móveis do mundo e curiosamente fica numa cidade minúscula de apenas 25 mil habitantes bem no centro dos EUA. O time da HNI, que não é pequeno, já conta com uma dúzia de brasileiros então não vou ficar completamente sozinho nesse novo ambiente. No entanto, a dor de barriga é grande, pois é uma mudança enorme deixar tudo que construi aqui no Brasil para começar uma vida nova fora do pais.

Não posso afirmar com certeza se vai ser para sempre, mas a curto prazo não pretendo voltar pro Brasil (só a passeio :) ).

O blog continua, mas provavelmente começarei a escrever em inglês apenas. Acredito que isso não seja um problema porque a grande maioria dos leitores aqui do blog e do público em geral de TI se vira bem no idioma. Minhas outras participações na comunidade também continuam de maneira remota e com uma experiência diferente e cheia de uma nova visão.

Bão...era isso! :)

Wish me luck!

Hello and Farewell!

2009-04-20T15:21:30+00:00

Hmmm.... bastante tempo sem escrever já né? Quase um mês!

Nestas últimas semanas muitas coisas aconteceram e não sobrou tempo e nem paciência para escrever. E olha que eu adoro escrever, principalmente quando tem coisas legais para falar.

Mas...não vai ser hoje ainda que vou escrever. Depois de três anos sem férias, finalmente saio hoje e volto 04/05. Espero voltar renovado, pois foi um ano complicado e cansativo.

Meu projetinho de FTP com Rails andou e quero postar a respeito e também pude usar bastante (não o suficiente ainda) da API do Google Maps que é muitoooo legal! Na volta com certeza vou escrever sobre.

E se tudo der certo...terei algumas novidades.

Até lá!

Ruby on Rails e WinDBG

2009-04-03T23:46:39+00:00

Não, não, não! Uma coisa não tem nada a ver com a outra. Não é um post falando de como debuggar rails utilizando o WinDBG. Mas um único post dando dicas de boas referências sobre o assunto.

Ultimamente não tenho mexido muito em código. Na verdade não tenho visto nada técnico, pois estou atolado de propostas pra fazer (quem mandou não estudar? :) ). Mas...hoje quando cheguei em casa decidi que iria dedicar algum tempinho para mexer em algo interessante e diferente. Foi ai que topei primeiro com rails que eu já queria começar a estudar e depois com o WinDBG numa dica que veio do Twitter do André Nobre.

Ruby on Rails

Há alguns dias instalei o ubuntu em uma VM aqui em casa e montei todo o ambiente Rails para começar a fuçar. Apesar de ainda não ter concluído e contrariando as dicas do Rafael Rosa que disse para eu fazer algo mais simples, iniciei a construção de um programinha de FTP web em Rails. Na verdade, hoje eu parei num "Hello World". De qualquer forma, para quem está curioso para começar a mexer e ver o poder da ferramenta decidi disponibilizar alguns links que eu já havia encontrado e que o Rafa me passou. Ai vai:

RubyInside - Maior portal Brasileiro sobre notícias de Ruby. Primo do site gringo http://www.rubyinside.com.
RailsCasts - Diversos screencasts gratuitos a respeito de Rails. Cobre diversos assuntos com exemplos.
RubyQuickRef - Site contendo uma referência rápida as classes de Ruby.
Rails Guides - Segundo o Rafa, site que contém guias obrigatórios para os Railers que além de ensinar a programar em RoR, ensina "in the rails way".
Rails API - Toda documentação da API do Rails.
Ruby API - Toda documentação da API do Ruby.
Micro-tutorial Rails Parte 1, Parte 2 e Parte 3 - Micro-tutorial sobre Ruby no blog do AkitaOnRails. Desde o básico até alguns conceitos avançados.
Montando ambiente Rails em Windows - Tutorial ensinando a montar o melhor ambiente Rails em Windows também do AkitaOnRails.
Blog do Rafael Rosa - Várias coisas a respeito de Rails e também de Asp.NET MVC :)

Esses são só alguns. Com certeza tem muito mais e espero colocar mais informações a respeito de Rails conforme eu for mexendo!

WinDBG

Debuggar código é uma arte. As vezes mais difícil do que criar código do zero. Afinal, quando debuggamos código que não é nosso temos que entender o que quer dizer e as vezes é tão mau escrito que é triste de ver...

Além do debug que estamos acostumados, dentro do VS existem debugs mais baixo nível que podemos fazer. Lá na CLR e no Windows, quando as fronteiras já passaram nossa aplicação. Praticamente coisa de louco!

Não é um assunto simples, nem tão pouco fácil de aprender. Há alguns meses navegando nos blogs da Microsoft encontrei o blog da Tess Fernandes que é engenheira da Microsoft. A menina é du mau e ela fala basicamente de debugging e assuntos relacionados a performance. O problema é que muito dos tópicos sobre debug que ela aborda são muito avançados para newbies como eu.

Ai é onde entra o blog do André Nobre que já tem diversos posts em português e em um nível iniciante para ajudar as mentes mais ignorantes neste assunto como é meu caso. Alguns dos posts inclusive são em formato de screencast com demos. Vale a pena conferir para aprofundar um pouquinho mais nesse assunto e conhecer uma outra alternativa para descobrir porque aquela maravilhosa aplicação que desenvolvemos não funciona como deveria. :)

Enjoy!

Procura-se parceiro/sócio

2009-03-25T18:44:56+00:00

Quem acompanha o blog e/ou me conhece sabe que já a algum tempo tenho várias idéias de produtos e serviços que poderiam ser oferecidos e que dariam uma graninha a médio e longo prazo. No entanto, nunca coloquei nenhuma dessas idéias em prática, mas um dia chega a hora né?

Não sei se é uma coisa comum oferecer parcerias e sociedades em blog, mas como já estou chegando em quase cem assinantes (de acordo com o feedburner) acho que o público e a visibilidade são propícias. Pode ser que não de em nada, mas não custa tentar.

Estou sem escrever a alguns dias, pois nesse tempo estava pensando e colocando algumas idéias no papel, maquinando como poderia arquitetar um ou outro projeto.

O que eu preciso então? Qual a idéia do parceiro/sócio?

Desde sempre, fui e sou desenvolvedor de software, mas nunca tive muito tato para design, usabilidade e marketing. Acho que essas áreas de conhecimento são fundamentais para qualquer oferta de sucesso, pois não adianta de nada termos o melhor produto do mundo se ele não for fácil de usar, bonito e tiver um bom apelo comercial. Portanto, procuro alguém com essas habilidades para formar uma parceria para trabalhar com produtos e serviços web. Por conta disso, quem quiser tem que gostar muito da coisa.

Neste momento, não consigo oferecer nenhum incentivo financeiro ou prometer qualquer retorno em curto prazo, mas é por isso que procuro alguém para trabalhar junto comigo e não para mim.

Tudo que posso oferecer é muita vontade em construir algo próprio e boas idéias. :)

Claro que qualquer necessidade financeira não muito grande que venha a ser necessária para fazer o negócio andar pode ser suprida, mas tudo com muita calma.

A preferência é para as pessoas que forem de São Paulo, pois é onde moro e dessa forma ficaria muito mais fácil tocar o negócio. Não que seja impeditivo trabalhar com alguém de fora, mas com certeza será mais um desafio a ser vencido.

Se alguém tiver interesse e vontade de ser dono do próprio nariz dentro de algum tempo favor entrar em contato por email ou me adicionar no MSN para conversarmos.

Pré venda, negociação e propostas em Modelo Ágil. Como fazer?

2009-03-14T16:11:16+00:00

Ontem participei de um evento da Stefanini sobre agilidade junto com o André, Alexandre Magno da Adaptworks e Fábio Kung da Caelum e como não podia deixar de ser, esse assunto surgiu: como vender este tipo de serviço? Como elaborar propostas que estejam alinhadas com modelo ágil e que não exponham exclusivamente o fornecedor e ao mesmo tempo sejam atrativas ao cliente? Infelizmento como esperado, não existe resposta exata para essa pergunta (ainda?).

No entanto, existem algumas abordagens que podemos utilizar a fim de chegar em um consenso. Vou falar um pouquinho a respeito e se alguém tiver algo a contribuir, será melhor ainda.

Atualmente vendemos software na ilusão de que alcançaremos prazo, custo e escopo sem surpresas. Mas... isso não é verdade. Nunca foi. Trabalhar dessa maneira, a não ser que seja em um ambiente conhecido e extremamente controlado quase sempre nos leva a fracassar em um desses pontos, quando não em todos.

O ideal nesse caso, é sentar com quem vende, com quem elabora contratos, com a área jurídica e com quem executa e procurar o modelo ideal para sua oferta de agilidade. Scrum, XP, MSF são apenas modelos de gerenciamento de projetos e engenharia, que não dizem como realizar essa venda. Isso não é o papel dessas ferramentas. Cada empresa deve encontrar sua forma de trabalhar essas ofertas.

Se utilizarmos métodos ágeis e iterativos em uma proposta de escopo fechado das duas uma: ou não vamos efetivamente trabalhar de maneia iterativa, pois precisamos controlar o escopo o tempo todo ou como fornecedores vamos tomar prejuízo, pois provavelmente o escopo será maior do que o contratado já que não conseguimos medir de maneira confiável o escopo de um projeto em tempo de proposta.

Fora do Brasil um modelo de venda que já é muito aceito e difundido é o "Tempo e Material" (Time and Material) que é basicamente trabalhar "hora aberta", ou seja, o fornecedor recebe X por cada hora trabalhada. Posso afirmar com certeza que essa é a melhor maneira do fornecedor de trabalhar com metodologias ágeis já que não temos um cronomêtro financeiro em contagem regressiva. Mas será que essa é a melhor maneira pro cliente? Muitos deles dizem que sim, pois se a consultoria aplicar realmente um modelo ágil é fácil medir e verificar se o trabalho está sendo feito e se está sendo feito de maneira adequada atendendo as expectativas e objetivos do cliente. O problema é que nosso mercado, principalmente as repartições públicas, não estão preparadas para isso, ainda. Fornecedores e clientes ainda não se entenderam a ponto de confiarem uns nos outros e acreditar que esse modeo colaborativo funciona melhor do que o baseado em documentos que-me-protegem-de-qualquer-mudança ao qual estamos acostumados. Enquanto isso não acontece (e tenho fé que vai acontecer!) temos que continuar vendendo e comprando e trabalhando para alcançar os objetivos do cliente.

Para diminuir um pouco esse medo dos clientes de serem enganados e gastarem demais e diminuir o risco do fornecedor na presação de serviços existem algumas coisas que podemos fazer.

Uma delas é adicionar uma cláusula de fuga nestes contratos "hora aberta" que permite que, caso um cliente ou até mesmo o fornecedor não esteja satisfeito com o andamento do projeto, este possa cancelar o contrato sem onûs para ambos os lados. Dessa forma, é possível "obrigar" tanto ao fornecedor quanto ao cliente a trabalharem em conjunto, pois se qualquer um pisar na bola o outro pode sair fora num piscar de olhos.

Outra maneira é elaborar um contrato de preço fixo e com tempo estimado utilizando qualquer técnica com as quais já estamos acostumados, mas não fixar completamente o escopo do projeto ou então garantir que apenas uma parte do escopo seja entregue. Talvez algo entre 60% e 80%. Isso também diminui um pouco o risco do fornecedor em dar um preço fechado e ao mesmo tempo garante ao cliente que ele terá seu sistema desenvolvido com um método de qualidade mesmo sem ter 100% de escopo definido em proposta entregue. Na verdade, muitas vezes isso nem é necessário já que o principrio de pareto afirma que 80% dos benefícios gerados por um sistema são proporcionados por apenas 20% das funcionalidades.

Seja qual for a maneira que você trabalha, o mais importante é estar alinhado com seu cliente e trabalhar de maneira honesta e transparente porquê se você for sinero e honesto e realmente ajudar seu cliente a atingir seus objetivos, ele provavelmente não irá te deixar na mão. Isso também vale para clientes. Se você ajudar seu fornecedor e não procurar tirar vantagem de contratos que obriguem ele a ter prejuízo com certeza ele não irá faltar com você e te ajudará a crescer.

Referências adicionais

José Papo Website - Apresentações e informações a respeito de contratos ágeis

Improve IT - Modelo de contrato ágil

Como gerenciar versões de banco de dados - Parte 2

2009-03-08T00:42:17+00:00

Na primeira parte falei um pouco dos problemas envolvidos no controle de versionamento de banco de dados. Agora esta na hora de apresentar alguma solução, certo? :)

Apresentando Migrator.NET

Para resolver a maioria (senão todos) os problemas de versionamento de banco temos uma ferramenta maravilhosa chamada Migrator.NET. Essa ferramenta é um port para .NET do original em Rails. A idéia por trás dela é bastante simples: consiste em diversos objetos (classes) versionados (da mesma maneira que código normal) contendo as instruções que devem ser executadas para gerar e/ou voltar o schema do banco de dados. Cada classe corresponde a uma instrução de alteração e contém um método Up (adicionar/avançar) e um método Down (retroceder/fallback) equivalente. Vejamos como é facil no exemplo abaixo:

#region Usings

using System.Data;
using Migrator.Framework;

#endregion

namespace NetScrum.Migrations.Tables
{
    [Migration(20090209211900)]
    public class CreateTableProject : Migration
    {
        public override void Down()
        {
            Database.RemoveTable("netscrum_project");
        }

        public override void Up()
        {
            Database.AddTable("netscrum_project",
                new Column("id", DbType.Int32, ColumnProperty.Identity)
                , new Column("name", DbType.AnsiString, 100, ColumnProperty.NotNull)
                , new Column("description", DbType.AnsiString, 300, ColumnProperty.Null)
                );

            Database.AddPrimaryKey("pk_project", "netscrum_project", "id");
        }
    }
}

Viram? Basta referenciar a DLL Migrator.Framework.dll, adicionar a diretiva using criar sua classe herdando de Migration e dar override nos métodos Up e Down.

Gerenciando as versões

Para gerenciar as versões e garantir que os migrations sejam executados na ordem correta, você deve utilizar o atributo Migration(long version) decorando a classe. Você deve preenche-lo com um long contendo o timestamp no formato AAMMDDhhmmss (ano/mes/dia/hora/minuto/segundo) em que seu migration foi gerado. Ou seja, um alter table da tabela projeto, por exemplo, deve conter um valor mais novo (maior) que o create table correspondente para que o migration de create seja executado antes do alter.

Configurando o build

Criar e gerenciar migrations é muito fácil. No entanto, as configurações dele são um pouquinho chatas para quem não está familizarizado com MSBuild ou NAnt. Neste artigo vamos usar o MSBuild que já é nativo e eu gosto mais simplesmente por estar familiarizado.

Junto com o código fonte compilado do Migrator.NET vem também o assembly Migrator.MSBuild.dll que é onde está a o target especifico que o MSBuild precisa para executar os migrations. Este target será usado no arquivo de build (explicado mais abaixo) e deve ser configurado como o exemplo abaixo apontando para o caminho onde esta o assembly. Arquivos Migrator.Targets:

 $(MigratorTasksPath)\Migrator.MSBuild.dll

A propriedade $(MigratorTasksPath) define onde está o assembly Migrator.MSBuild.dll. O valor desta propriedade pode ser hard-coded ou então preenchida no arquivo de build conforme veremos.

Por padrão, todo projeto (arquivo.csproj no caso de C#) é um arquivo de MSBuild. É possível editá-lo para incluir as configurações necessárias ao Migrations, mas cedo ou tarde é perigoso que Visual Studio o recrie ou o modifique a seu bel prazer e ai perderiamos as customizações. Portanto, prefiro criar um outro arquivo de build exclusivo para os migrations e chama-lo quando eu bem entender. Segue abaixo o arquivo NetScrum.Migrations.build:

 $(MSBuildProjectDirectory)

Este arquivo define uma série de paramêtros:

MigratorTasksPath - Caminho utilizado para apontar onde esta o target (mencionado acima). Neste caso, é preenchido pela propriedade $(MSBuildProjectDirectory) que aponta para onde o arquivo build que está sendo chamado está localizado.
DatabaseVersion - Será passado via paramêtro na hora da chamada do Migrator.NET. Caso não seja informado, o valor default é -1 que indica para a última versão.
Provider = Banco de dados de destino. Neste caso estamos usando SqlServer, mas Migrator.NET funciona para outros bancos também.
Connectionstring - Óbvio, né? :)
To - Recebe o valor do parametro DatabaseVersion indicando a versão de destino do migrations.
Migrations - Caminho onde se encontra o assembly compilado contendo as migrations.

Existem alguns outros paramêtros que permitem uma configuração um pouco diferenciada, como por exemplo, ao invés de fornecer o assembly compilado apenas informar o caminho onde estão as classes para que o próprio Migrator.NET faça a compilação.

Uma vez que tudo esteja configurado, basta ir até o command prompt, navegar até a pasta onde o arquivo.build e chamar o MSBuild passando os paramêtros conforme o exemplo abaixo:

%windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe NetScrum.Migrations.build /t:Migrate /p:DatabaseVersion=-1

Os paramêtros são:

NetScrum.Migrations.build - Nome do arquivo de build que contém as configurações do Migrator.NET
/t:Migrate - Target que deve ser executado. Neste caso o target de migrations :)
/p:DatabaseVersion=-1 - Versão do banco para qual desejo ir. Caso queira ir para última versão é só informar -1. Caso queira zerar o banco (executar Down de todas as migrations) é só informar 0. No caso de ir para uma versão específica é só informar o timestamp desejado.

É isso! Configurar a primeira vez é um pouco chato. Acertar os caminhos dos arquivo requer algumas tentativas para quem não está familizarizado com o MSBuild, mas nada muito traumático. Nos exemplos, todos os arquivos necessários (menos o assembly contendo as migrations) estavam na mesma pasta (tools) para facilitar.

Exemplo

Quem quiser ver o exemplo funcionando, basta baixar a última versão do .NET Scrum. Ele contém as pastas e arquivos configurados direitinho pra funcionar.

Importante

A versão utilizada para este artigo foi a 0.8 que baixei tem uns 45 dias. Na época, apesar de compilada não estava funcionando então tive que efetuar umas pequenas correções do trunk. Não testei a versão 0.8 disponível hoje, portanto você pode baixar aqui a versão 0.8 compilada e corrigida por mim.

Referências

Até alguns dias atrás eu não tinha encontrado nenhum outro artigo a respeito deste assunto em português. Acredito que ainda não exista e esse seja o primeiro. Além das instruções básicas de banco que foram apresentadas no migration do exemplo ainda é possível criar PKs, FKs, executar Sql's open text entre outros procedimentos não descritos aqui.

Vocês podem encontrar informações a respeito desses procedimentos no site do projeto ou tirar dúvidas e perguntar aqui mesmo no blog.

Enjoy!

Pai Rico, Pai Pobre: Resenha

2009-03-03T12:00:14+00:00

Livro meio clichê, né? Mesmo assim é muito bom!

Li esse livro de um pouco menos de 200 páginas escrito por Robert Kiyosaki e Sharon Lechter há quase dez anos atrás. No entanto, recentemente decidi le-lo novamente. Sei que nada tem a ver com o assunto do blog, mas acho super pertinente comentar a respeito do livro pelo seguinte motivo: informática não é uma profissão regulamentada no Brasil e até onde sei a maioria dos empregados das empresas ainda é contratado na forma de pessoa júridca. CLT ainda não é uma realidade para todos e eu particularmente acho uma boa, pois acredito que cuido melhor do meu dinheiro do que o governo (mas isso é assunto pra discutir numa mesa de bar, ehhee...).

Como não temos uma aposentadoria garantida pelo governo e temos salários relativamente altos em relação a outros mercados é fundamental que saibamos como cuidar de nosso dinheiro para que no futuro não tenhamos que depender de parentes, amigos ou o que é pior ainda: do governo.

Pai Rico, Pai Pobre é um livro bem antigo que apresenta em uma linguagem muito simples como aumentar sua inteligência financeira para começar a caminhada a fim de atingir independência financeira. Através da história de um garoto que cresceu tendo dois pais, um rico e um pobre, é possível aprender o que é um investimento, diferenciar um ativo de um passivo e diversos outros termos que rodeiam o mundo financeiro.

Além desse aprendizado, ele nos desafia a pensar se realmente trabalhar com afinco do começo ao fim da vida é a melhor opção. Existe outra? Claro que sim! Podemos colocar nosso dinheiro para trabalhar para nós. Mesmo que iniciemos com pouco dinheiro, é possível montar uma riqueza inimaginável. Afinal, os grandes donos de empresas e milionários que vemos por ai não nasceram ricos (pelo menos não a maioria) e começaram com pouco.

Além deste livro, o mesmo autor escreveu uma série de outros livros de mesmo assunto para apoia-lo nessa caminhada. Além dos assuntos técnicos que estudo, também estou estudando mercado financeiro, investimentos, etc, mas não pretendo ficar discutindo sobre isso aqui no blog (o objetivo do blog não é esse). Então se alguem quiser bater papo a respeito pode me contatar diretamente, ok?

Enfim, a idéia do post é mais dar uma dica no sentido de que devemos aproveitar enquanto somos novos para começar a montar um patrimônio que nos permita viver bem e desfrutar a aposentadoria.

Hoje tenho 22 anos, estou começando essa caminhada agora e quero me aposentar antes dos 40 para curtir um pouco da vida. E você? Quer trabalhar a vida inteira e ainda assim depender de terceiros no final da vida? Eu não quero!

Como gerenciar versões de banco de dados - Parte 1

2009-03-01T16:19:52+00:00

Quando estamos desenvolvendo software, seja ele um produto com desenvolvimento contínuo (como o Wordpress, por exemplo) ou um sistema customizado para um cliente nos deparamos com um problema no mínimo chato de resolver: gerenciar as versões do banco de dados (tabelas, procedures, etc) que evoluem ao longo do projeto. Vou apresentar a vocês em um artigo com duas partes uma solução que tem me trazido paz e segurança nos últimos tempos e que talvez possa te ajudar também.

O problema

Controlar o código fonte que é compilado pela nossa ferramenta de trabalho é uma tarefa que já foi bem complicada, mas que se tornou relativamente fácil com a evolução dos próprios editores de código (Visual Studio) e dos repositórios de código (TFS, SVN, CVS, etc). No entanto, não podemos dizer o mesmo dó código fonte que utilizamos para nossa aplicação acessar bancos de dados. Na maioria da vezes esse código não é compilado e por mais que existam checagens de sintaxe os erros tendem a aparecer na hora que estamos desenvolvendo a versão 2.1 do sistema e precisamos recuperar versão 1.5 para corrigir bugs. Isto, quando esse controle é feito de alguma forma e esse processo é possível, pois na maioria das vezes tudo que as pessoas mantém são os dados no próprio SGBD sem nenhum controle de versão.

Gerenciar a versão do banco de dados quer dizer que no momento em que eu recuperar a versão XYZ do meu sistema também vou conseguir recuperar os artefatos de banco (tabelas, procedures, triggers, etc) correspondentes a esta versão, restaurando desta forma o sistema em um ponto estável tanto do ponto de vista de estrutura quanto do ponto de vista de dados.

Além dos pontos falhos óbvios que essa falta de controle apresenta existe mais um problema que considero grave e que, inclusive prejudica a aplicação de práticas ágeis como integração contínua e testes automatizados. Existindo a necessidade de efetuar esse controle de maneira manual fica impraticável a execução dessas práticas, pois para executá-las durante todo o tempo tudo (incluindo os scripts de banco de dados) que compõe o sistema deve permitir automatização.

As opções existentes

É claro que não posso falar por toda a comunidade de desenvolvimento Microsoft, mas a grande maioria dos projetos que já participei ou conversei a respeito com outros colegas de plataforma tinha pouquissimo (não confiável) ou nenhum controle deste tipo. Geralmente as pessoas efetuam este tipo de controle de duas formas:

Como se fosse código-fonte normal - Scripts de create table, procedures e demais artefatos são mantidos em diversos arquivos SQL (ou em um linguição) no repositório de código e o desenvolvedor utiliza eles na hora em que precisa avançar ou restaurar uma versão. O maior problema desta técnica é que como o desenvolvedor não precisa efetivamente gerar scripts de banco de dados para modificar o banco, pois pode faze-lo pela ferramenta RAD com arrasta-estica-e-puxa dificilmente ele gera esses scripts depois da primeira vez e mais raramente ainda ele gera esses scripts de maneira correta. No final, temos uma salada de scripts: alguns utilizando alter table, outros modificando um script de create já existente, diversas versões da mesma procedure e possívelmente nenhum daqueles scripts de carga feitos pelo joãozinho no começo do projeto. Dessa forma, é impossível ir para a versão de banco de dados desejada de maneira fácil e sem dores de cabeça.
Mantendo tudo no banco de dados - A maioria dos desenvolvedores, infelizmente, se preocupa pouquissimo com o futuro do projeto e estão preocupados apenas com suas tarefas atuais. Dessa forma, qualquer atalho para terminar uma tela mais rápido é bem vindo, mesmo que este atalho cause um grande problema no futuro. Por este motivo, muitas pessoas mantem a estrutura de banco de dados apenas no SGBD. Alguns projetos inclusive não tem nem um modelo de dados em uma ferramenta como o ErWin ou DBDesigner por exemplo. Agora vamos imaginar que por algum motivo o banco de dados de desenvolvimento foi pro espaço. Se não tiver alguém da equipe que mantem um backup local o projeto está perdido. Possívelmente milhões $$$ perdidos por preguiça e falta de organização.

A Microsoft tentou no Visual Studio Team System Database Edition com o projeto de banco de dados (somente para SqlServer) uma alternativa a essas maneiras, mas infelizmente não obteve sucesso. A idéia é manter um projeto que por meio de um banco de dados local simula a compilação dos scripts diminuindo os erros de deploy. No entanto, todo este processo é lento, obriga o desenvolvedor a ter um SqlServer instalado localmente e tem uma série de limitações como não poder acessar outros bancos diferentes do banco com qual o sistema trabalha e de outros providers (Oracle, MySql, etc.). Ainda não testei o VSTS 2010, mas não acredito que seguindo esta receita seja possível obter muito sucesso.

A solução

Para resolver este problema, o ideal seria que pudéssemos tratar dos objetos de banco da mesma maneira que tratamos os objetos do nosso sistema. Objetos que compilam efetivamente nos oferecem mais segurança, ainda mais se estes forem construidos utilizando uma API simples e padronizada que possibilite o deploy em bancos distintos. Melhor ainda se o desenvolvedor não precisar ter muito trabalho para efetuar este controle, pois se o processo exigir muito trabalho ninguém irá utilizá-lo.

No próximo post, vou falar sobre o Migrator.NET que oferece essas características que apresentei no paragráfo anterior de uma maneira rápida e fácil de usar. :)

Link para parte 2

Channel 9 Brasileiro

2009-02-21T16:57:18+00:00

Essa vale repassar. Agora temos a versão brasileira do Channel 9; ponto central para acompanhar vídeos e podcasts em português. :)

Impulsionando a produtividade pessoal: conhecendo GTD

2009-02-18T22:27:39+00:00

Era uma vez um cara que não conseguia desligar sua cabeça das atividades que tinha que fazer. O tempo todo ele ficava pensando no que tinha que fazer e principalmente no que estava deixando de fazer. Um dia esse cara ficou louco e largou tudo!

Quem é que nunca se sentiu assim? Seja durante um projeto, uma fase ruim da vida ou mesmo durante todo o tempo. Há cerca de um mês atrás eu estava me sentindo dessa forma (isso não quer dizer que eu não precise de férias :) ). Só que antes de ficar louco e largar tudo como na historinha acima decidi fazer alguma coisa a respeito. Foi quando encontrei uma técnica fabulosa chamada GTD oriunda do inglês Getting Things Done traduzida livremente em português para Fazendo as coisas acontecerem.

Quando você tem projetos que de alguma maneira participa ou atividades/objetivos/metas que deve cumprir (com certeza todos nós temos vários) é inevitável que sua mente fique ligada tomando conta disso tudo pra você. O problema é que nesse ponto nosso cerébro não é tão inteligente assim e lembra você de coisas que você tem que fazer, mas geralmente nas horas erradas.

De que adianta meu cerébro me lembrar de fazer a matrícula da faculdade hoje se as inscrições serão abertas apenas em junho? De que adianta ele me lembrar de comprar fraldas no momento que já cheguei em casa vindo do super mercado? Não adianta de nada! Dessa maneira, apenas problemas são causados e o resultado é que você fica ligado o tempo todo sem descanso por nem um minuto.

Mas por que isso acontece? Porque o cerébro não conhece nenhum sistema externo a ele em que confie para fazer esse controle. Enquanto não houver um sistema em que onfie, ele irá fazer esse trabalho (que percebemos que ele não faz muito bem...). É ai onde entra uma técnica que possibilite seu cerébro relaxar e ao mesmo tempo te manter no controle ~~isso se você ainda tiver algum~~.

GTD é uma técnica de administração de tempo e de produtividade criada por David Allen que tem como objetivo limpar sua mente e deixa-lo num estado de controle relaxado, sem neuras e stress.

O fluxo é bastante simples e pode ser visto na figura mais abaixo. São basicamente 5 etapas:

Coletar - É a primeira parte do processo. Neste momento você deve pegar absolutamente tudo que tem a fazer e colocar em um lugar, algo como uma caixa de entrada. Você pode usar uma caixa literalmente ou então uma ferramenta no seu computador. Eu recomendo a utilização de um compartimento físico, pois representa efetivamente a realidade e não apenas uma abstração. Pros itens "virtuais" que devem ser processador você pode criar um cartão e colocar dentro da caixa. A partir do momento que você inicia a aplicação da técnica tudo de novo que surgir deve ir para sua caixa de entrada. Desde contas a pagar até uma ligação que você deve fazer para um amigo no dia de seu aniversário.
Processar - Se você coletou direitinho seu itens, neste momento você deve ter uma enorme pilha de coisas a executar. O problema é que nem tudo é passivel de ação neste momento. Algumas coisas você precisa fazer em determinada data, outras dependendem de terceiros e outras você não quer fazer em um futuro próximo, por exemplo. Isto é processar. Você vai parar 1 minuto e pensar o que fará com cada um dos itens.
Organizar - Uma vez decidido o que fazer com o item, você deve organizá-lo em um dos locais apropridados. Podem ser:
1. Lixeira - Isso não serve pra nada? Não consegue ver valor? Lixo! Não tenha dó, pois dessa maneira você só irá acumular tranqueiras.
2. Algum dia/Talvez - "Viajar para acapulco no México". Não é algo que você possa fazer agora, mas quer fazer algum dia. Muito bem, vai para uma lista exclusiva para esse tipo de itens.
3. Referências - Seu amigo te passou um artigo super interessante que você não irá usar no momento, mas pode vir a servir para alguma coisa? Coloque-o em uma pasta só para consultar futuras.
4. Fazer agora - Você precisa ligar para sua namorada avisando que precisa da ajuda dela no final de semana. Isso demora menos do que dois minutos. Então faça agora mesmo!
5. Delegar - Isso não depende de você, mas você precisa saber do resultado ou acompanhar por outro motivo. Coloque em uma lista separada, delegue ao responsável e fique tranquilo.
6. Agenda - Consulta médica daqui 30 dias. Marque no calendário (físico ou virtual). Ele vai garantir que você não se esqueça.
7. Projetos - Existe algo que precisa de mais de uma ação física para ser completado? Talvez "construir uma casinha para meu cachorro". Para executar isso você precisará orçar os materiais e fazer um plano antes de executar a construção. Essas ações devem ficar agrupadas em pastas separadas para projetos. Uma por projeto.
8. Próximas ações - Nesta lista vai as ações que você deve executar que não encaixaram em nenhuma outra lista e que você irá fazer assim que tiver um tempo livre. Por exemplo: "ler post a respeito de GTD no blog do Tuca" :)
Executar - Uma vez que você tenha tudo organizado chegou a hora de executar! Eu costumo começar pelo que é mais importante e depois executando a lista de "Próximas ações" conforme possível. É importante ter uma meta pessoal ou objetivo a ser alcançado (lembra daquelas promessas de ano novo?), pois eles podem te guiar na escolha do próximo item a ser executado.
Revisar - Este momento é que torna possível o funcionamento do processo. Pelo menos uma vez por semana é necessário que você tire um momento em que possa ficar tranquilo para revisar os itens da sua lista, removendo os completos, processando e organizando os novos itens e acompanhando os itens que você delegou. Eu faço este processo uma vez por dia pelo menos. Isso garante que eu não esqueça de nenhum compromisso e também que minha caixa de entrada não fique cheia.

O processo é bastante simples e você pode usar diversas ferramentas para executá-lo. Ir atrás de ferramentas é inclusive divertido e motivador. Num post futuro vou detalhar um pouco mais a respeito das ferramentas que utilizo, mas entre elas estão: o RememberTheMilk para atividades virtuais e referências, um bloco Moleskine Reporter para anotações e idéias para usar quando não tenho acesso ao computador e um rotulador eletrônico que me ajuda a organizar os itens na minha caixa física.

Iniciei os estudos comprando o livro do David Allen que tem cerca de 200 páginas na Livraria Cultura por R$44,00.e desde que estou aplicando o método na vida pessoal e profissional (é quase impossível separar) senti uma melhora sensível na minha organização, no cumprimento de objetivos e atividades e na concentração enquanto executo alguma coisa. Afinal, meu cerébro não precisa mais se preocupar em cuidar das minhas pendências porque tenho um sistema para isso! :)

Foi um post longo e com toda a certeza não é possível passar todos os detalhes de como aplicar essa técnica, mas a idéia é mostrar por onde começar e mais importante, mostrar que existe uma maneira de manter o controle de suas atividades de uma maneira tranquila e relaxada sem precisar arrancar os cabelos (se você tiver).

Além do livro, segue abaixo diversas outras referências que podem ajudar, em vídeo inclusive.

Efetividade.NET - Blog a respeito de produtividade com diversas dicas e métodos para ser mais efetivo.
43 Folders - Blog americano também a respeito de produtividade.
LifeHack - Site em inglês com dicas hacks para melhorar seu dia a dia.
Técnica Pomodoro - Outra técnica de organização que bloguei anteriormente

E pra finalizar um vídeo do próprio autor em uma palestra sobre GTD

Espero que gostem e aproveitem!

EDIT: Produtos Moleskines até pouco tempo atrás não eram vendidos no Brasil, mas agora você pode encontrar na Livraria Cultura. Nas lojas físicas e online. Valeu por lembrar Victor!

Integração Contínua com .NET

2009-02-13T15:30:09+00:00

E o Twitter já traz bons resultados! eheehe... :)

O Bruno acabou de me passar um link excelente que vale compartilhar com vocês aqui. Um guideline criado por Carel Lotz com passo a passo para montar um processo de Integração Contínua completo!

Have fun!

Eu no Twitter

2009-02-12T17:28:32+00:00

Até então sempre subestimei esta ferramenta. Há alguns dias atrás comecei a dar uma olhada no Twitter de algumas pessoas e acabei achando bacana.

No começo eu estava meio relutante, mas me passaram o add-on TwitterFox que ajuda muito!

Enfim, estou no Twitter. :)

Follow me!

Como aprender TDD?

2009-02-12T17:03:49+00:00

Test driven development não é uma das práticas mais fáceis de se aprender. Por experiência própria, posso afirmar que no começo geralmente as pessoas se empolgam, mas logo -em menos de duas semanas- a empolgação foi embora assim como a escrita dos testes.

Isso acontece, pois durante este período o desenvolvedor ainda está aprendendo como a coisa funciona e não tem certeza se esta dando certo ou não. Além disso, esbarramos vez ou outra em código legado que ~~inviabiliza~~ dificulta os testes. Isso é normal, não só com TDD, mas com uma série de práticas/tecnologias que temos que aprender para melhorarmos nosso produto final.

O importante é esperar este período e continuar se esforçando para que os resultados comecem a aparecer.

Recentemente a InfoQ BR traduziu um excelente artigo de Mark Levision sobre este assunto que vale a pena conferir.

Team System na quinta reunião do DotNetArchitects

2009-02-01T21:20:23+00:00

No último sábado dia 31/01 aconteceu a quinta reunião do DotNetArchitects com a apresentação do André Dias a respeito do Microsoft Team System. Assim que o vídeo da apresentação estiver disponível coloco por aqui.

Essa, na minha opinião, foi uma das melhores reuniões do grupo até então. Acredito que por falar em um tema mais difundido do que os anteriores (Scrum e DDD) as pessoas participaram mais e houve mais discussão.

Fiquei feliz, pois sem querer querendo ganhei um voucher para certificação do André que distribuiu mais um de brinde além do meu (valeu!).

Livro grátis até dia 28 - SQL Server Integration Services

2009-01-22T23:08:16+00:00

Essa eu peguei no blog do Giggio. Até dia 28 deste mês a Microsoft está disponibilizando o livro "Sql Server 2005 - Integration Services Step by Step" de "grátis na faixa" para download. É necessário um rápido cadastro e zap! É só efetuar o download.

Enjoy!

Evento: .NET Architects Day 2009

2009-01-22T23:02:35+00:00

Apesar de ter sido fundada a pouco tempo o grupo .NET Architects já está a todo vapor e já vamos ter nosso primeiro grande evento presencial: ".NET Architects Day 2009".

O evento está marcado para dia 25 de abril em São Paulo e provavelmente participarei com uma apresentação, mas ainda não está 100% certo.

Mais informações podem ser encontradas na página do evento e conforme a programação e informações complementares forem saindo eu divulgo por aqui.

Participem e divulguem!

Personal Scrum: A técnica Pomodoro

2009-01-19T18:02:21+00:00

Achei hoje no blog do Henrik Kniberg a indicação de uma técnica que me parece ser excelente e gostaria de indicar a leitura a todos: Controle do tempo e atividades via Pomodoro

Estou terminando de ler, mas já da pra adiantar que é uma técnica de gerenciamento pessoal de atividades muito parecida com Scrum. Ela é baseada em uma lista de todo's para o dia a dia e espaços de tempos definidos e fechados para execução dessas atividades. Tudo muito simples e funcional, assim como Scrum.

Vou começar usar a partir de amanhã e comento sobre os resultados posteriormente. Vale a leitura!

Vídeo: Scrum em menos de 10 minutos

2009-01-16T21:59:23+00:00

Ultimamente nas apresentações que tenho feito no trabalho e nas reuniões do grupo temos falado muito a respeito de Scrum e muitas pessoas ainda não conhecem e me perguntam a respeito. Eu já falei bastante aqui, mas há aqueles que não tem paciência ou ainda não tem interesse suficiente pra ler tudo e se inteirar.

Para essas pessoas eu trago hoje um vídeo feito pelo Hamid Shojaee que apresenta Scrum em menos de 10 minutos. Não concordo com tudo que ele fala e com certeza algumas partes fundamentais ficaram fora, mas para dar um gostinho do que Scrum é vale a pena ver.

Segue o vídeo:

Outro material muito interessante de referência e complementar é um PDF famoso chamado "Scrum in Five minutes". Também vale como introdução e é rapidinho de ler.

É importante ressaltar que estes materias são bastante básicos e não são totalmente completos. Sendo assim é fundamental procurar outras fontes de informação antes de sair fazendo de qualquer jeito e dizendo que usa Scrum. Ok? :)

Windows 7. Funciona?

2009-01-12T21:52:46+00:00

Baixei ontem o Windows 7 e já estou usando desde então no meu HP dv2760br. A instalação foi muito rápida (acho que uns quinze minutos) e o Windows já reconheceu todos os drivers do notebook, só restando instalar os softwares adicionais controladores das frescuras do equipamento. Instalei também o Office 2007, Firefox e outros softwares menos importantes. Todos sem problemas.

Tá tudo rodando 100% perfeito e estou adorando o novo SO. Muito mais bonito, rápido e fácil de usar do que o Windows XP e o próprio Windows Vista. Nessa mão a M$ acertou! Essa semana ainda vou instalar ele nas minhas outras máquinas.

Portanto, fica ai a dica e o tranquilizante para os mais inseguros: podem instalar que tá bala!

Windows 7 Beta disponível para download

2009-01-11T14:00:57+00:00

O pessoal da Microsoft havia prometido que no dia 09/01 (sexta-feira) o Beta do Windows 7 estaria disponível para 2,5 milhões de download. No entanto, devido a procura o download foi retirado do ar e colocado novamente ontem a tarde, só que dessa vez sem limites de número de downloads até dia 24/01 quando os download encerrarão.

Esta versão do Windows é Beta então cuidado onde instalam. O trial ficará ativo até agosto de 2009 quando irá expirar.

O ISO Inglês 32 bits tem 2.2GB e estou baixando neste momento!

O link para download é http://www.microsoft.com/windows/windows-7/beta-download.aspx

Enjoy!

User Stories Applied - For Agile Software Development: Resenha

2009-01-05T22:50:07+00:00

Ano novo! Energias parcialmente renovadas (ainda não tive as férias que quero) e tempo de terminar a leitura de alguns livros que eu não conseguia me concentrar para ler durante o mês de dezembro devido ao burnout adquirido do último projeto.

Vamos lá!

Desde que eu escrevo a respeito dos livros que leio eu nunca escrevi aqui no blog qual a idéia por trás dos posts de resenhas que faço e acho que esse é um ótimo post para falar a respeito.

A idéia não é nunca foi escrever longos e chatos resumos de livros iguais aqueles que usávamos para as provas de literatura do colégio. Por dois motivo: a) É um pé no saco fazer esse tipo de trabalho e ao invés de ter prazer ao escrever esses posts eu me sentiria entediado (sem falar no tempo que levaria) e b) porque ninguém procura esse tipo de resumo (acredito eu) de livros técnicos ou relacionados a área técnica, pois o conhecimento contido nessas obras não pode ser absorvido apenas com um resumo.

Acompanhando a cronologia dos meus resumos é possível conhecer também um pouquinho mais a respeito de mim e quais focos estou dando para meus estudos. Isso é legal pra eu poder ver a qualidade das leituras que fiz ao longo do tempo quando olhar pra traz e pros leitores enxergarem um ser humano por trás deste blog e não apenas mais alguém escrevendo sobre tecnologia (até coloquei uma foto minha no about! :D).

Outro aspecto importante que eu procuro passar nesse tipo de post é o que eu buscava quando comecei a ler o livro e se efetivamente minhas ansiedades e expectativas a respeito do assunto foram atendidas. Além desses pontos também acabo indiretamente dando feedback de onde comprei os livros e fornecendo os preços para que quem quiser possa comparar e ver se está pagando mais caro ou barato.

E como não podia deixar de ser, falo um pouquinho a respeito dos pontos mais importantes do livro e que mais chamaram minha atenção.

Enfim, achei que como esses posts estão entre os mais visitados no blog valia a pena esclarecer as minhas motivações.

Agora é bom falar a respeito do assunto principal do post, né?

Este livro escrito por Mike Cohn é simplesmente f a n t á s t i c o!

Apesar de ter lido bastante a respeito deste assunto na internet e em outras referências ágeis menos específicas, desde que comecei a aplicar práticas e disciplinas ágeis, há algum tempinho atrás, eu vinha esbarrando em agluns aspectos desta técnica e não conseguia alcançar todos os benefícios oferecidos por ela.

Parece que a partir do momento que comecei a ler este livro uma luz se acendeu na minha cabeça. Luz essa que iluminou e sanou as dúvidas que eu tinha sobre o assunto e também a respeito de alguns outros tópicos que eu ainda não tinha uma informação muito concreta e corroborada.

Mike começa o livro falando do básico: o que são histórias, roles, personas, quando usá-las, testes de aceitaçao, como escrever histórias de qualidade seguindo o acrônimo INVEST (assunto pra outro post com certeza) e comparações com outras técnicas oferecendo inclusive uma excelente referência a respeito de casos de uso (use case). Terminar de ler essa primeira parte é mais do que suficiente pra aplicar a técnica já com um certo grau de exatidão e eficiência.

Mais adiante, ele aborda priorização (explicando o excelente acrônimo MoSCoW que com certeza será assunto pra mais um post futuro), estimativas e planejamento. Estes eram assuntos que não eram muito claros em minha mente e que com certeza estão muiiiiiito mais claros agora.

Mais pro final ele apresenta uma introdução rápida a respeito de Scrum e como utilizar as histórias em conjunto com Scrum e também uma introdução aos principais conceitos de XP.

Além da qualidade e quantidade de informações a respeito de user stories, Mike ainda apresenta alguns capítulos dedicados a um case real que começa da identificação das histórias, passando pela estimativa e priorização e indo até os testes de aceitação. Essa parte é importantíssima e agrega muito porque consolida através de exemplos reais (e não aqueles exemplos bobos que esbarramos constantemente) as informações apresentadas em todo o livro.

Se eu tivesse que recomendar um único livro para mudar a forma de pensar das pessoas e para que essas pessoas começassem a fazer software de uma maneira melhor, com certeza esse seria o livro. É "totalmente excelente"!

Me empolguei tanto escrevendo sobre o livro que já ia esquecendo das informações básicas de sempre: o livro possui 268 páginas e pode ser encontrado na Livraria Cultura por R$132,00 (paguei R$80,00 há dois meses atrás). Chegou no mesmo dia que comprei então pra quem não gosta de esperar é uma ótima pedida.

Recomendadissímo!

Resultado da terceira reunião do grupo DotNetArchitects - Com vídeo :)

2008-12-29T21:27:55+00:00

No último dia 13 tivemos a terceira reunião do grupo e os resultados podem ser vistos nesse post.

Os vídeos da apresentação do Giovanni sobre DDD e do debate posterior também já estão disponíveis para quem não pode ir ou tem interesse no assunto assim como os slides:

Apresentação

Debate

Slides

DDD > Experiencias from Giovanni Bassi

Olha como melhoramos! Em comparação com o material da minha apresentação, a gravação do áudio e vídeo já estão muito melhores.

Obrigado e parabéns novamente ao pessoal da UNIP que está apoiando a gente.

.NET Scrum - Projeto Open Source

2008-12-28T17:16:31+00:00

Há poucas semanas, batendo papo com o pessoal do DotNetArchitects, surgiu a idéia de utilizarmos uma ferramenta de gerenciamento de projetos Scrum pra cuidar dos das nossas atividades dentro do grupo.

Fui pesquisar, mas não encontrei nenhuma ferramenta gratuita web que pudessemos usar. Foi ai que surgiu o .NET Scrum. A idéia não é construir nada pra competir com o que existe por ai, mas utilizar da idéia pra ter um laboratório e construir um projeto onde possamos aplicar o que há de mais novo em tecnologia além de boas práticas de engenharia e condução de projetos.

Portanto, quem der uma olhada no projeto e quiser contribuir ou apenas acompanhar vai encontrar um ASP.NET MVC, jQuery, NHibernate usando interfaces fluentes, DDD, TDD, Spring.NET e outros frameworks e design patterns importantes para a construção de uma boa solução em .NET.

Se deixarmos de lado a parte tecnológica também é possível aprender um bocado trabalhando na organização de um projeto open source. Projetos de código aberto e mantidos pela comunidade são o maior caso de sucesso de times distribuidos trabalhando juntos a fim de atingir um objetivo. Se já é difícil obter sucesso em um projeto com o time no mesmo lugar, imagine trabalhar com pessoas que você nunca viu na vida e com comunicação relativamente limitada? Um grande desafio!

O Maurício Aniche que participa do DotNetArchitects já se juntou ao projeto pra me ajudar. Já existem alguns códigos publicados no codeplex e uma documentação miníma também. Quem quiser ajudar é mais do que bem vindo! :)

Boas festas!

2008-12-24T00:11:46+00:00

Neste último post do ano de 2008 eu quero desejar a todos os leitores os meus mais sinceros votos de boas festas!

Que todos (cada um a sua maneira) aproveitem bem o Natal e Ano Novo e que o próximo ano traga apenas coisas boas (mais) pra cada um de nós.

Aproveitem esses dias pra dar uma descansada (eu vou!), pois ano que vem vamos ter bastante coisa nova pintando por ai!

Feliz Natal a todos e próspero Ano Novo!!!

Scrum for Team System na MundoNET deste mês

2008-12-24T00:03:06+00:00

Recebi em casa e com certeza também já está nas bancas a edição número 12 (novembro-dezembro) da revista Mundo NET. Nesta edição meu artigo (escrito em conjunto com André) fala a respeito da utilização de Scrum junto com o Microsoft Team System como ferramenta e mais algumas dicas e cuidados que se deve ter na adoção de uma metodologia ágil como Scrum.

Além da minha contribuição a revista traz ainda artigos sobre Parallels Extensions pro .NET (que eu já comentei aqui), sindicalização ATOM e um super apanhado a respeito de coleções e estruturas de dados entre outros.

Não sei se foi só eu ou se outros leitores também vão ter a mesma reação, mas me espantei com a qualidade da impressão desta edição e da parte gráfica da revista que ficou muito legal, diferente do que estamos acostumados a ver.

Vale a pena conferir!

Hiperprodutividade em times Scrum

2008-12-17T22:23:19+00:00

Acabei de assistir a uma palestra feita pelo Jeff Sutherland no Google Tech Talks entitulada "Hyperproductive distributed Scrum teams" onde ele apresenta estudos de casos onde times distribuidos usando Scrum alcançaram um estado que ele chama de hiperprodutivo. De acordo com Jeff, nesse estado esses times são até dez vezes mais produtivos que times padrão.

Eu acredito que existem diversas formas de se executar um projeto, mas na minha humilde opinião nesta apresentação o Jeff Sutherland da a entender que Scrum é a única forma de se trabalhar e que serve pra todos os cenários e empresas. No entanto todos sabem que cada caso é um caso e que não existe uma única maneira que vai dar certo pra todos.

Não sei se é meu inglês que está meio enferrujado, mas durante alguns momentos da apresentação ele me pareceu muito arrogante falando de coisas que já viu e que está acostumado a ver. Não acho que é a melhor maneira de melhorar as coisas agindo desta forma.

Apesar desses dois pontos que eu não gostei muito é um excelente vídeo que acrescenta bastante no aprendizado e uso do Scrum.

No ar novamente

2008-12-16T19:01:14+00:00

Até que enfim! Estamos de volta!

Desde antes de ontem o host que hospeda meu blog vivenciou alguns problemas e só voltou hoje a tarde.

Peço desculpas pelo off-time, mas já passou. :)

Esses dias a coisa está corrida e não posto faz alguns dias, mas até o fim dessa semana espero voltar ao ritmo normal.

Domain-Driven Design, Eric Evans - Livro gratuito na web

2008-12-12T10:30:17+00:00

Navegando, há pouco, nas minhas feeds encontrei um post que o Giovanni publicou recentemente oferecendo o link para o livro "Domain-Driven Design: Tackling Complexity in the Heart of Software" do Eric Evans disponível gratuitamente na web através do Google Books.

Este é um dos livros que recomendo fortemente a leitura e que está na minha seção de indicados. Acredito que todo bom desenvolvedor deve dar uma boa lida, pois os benefícios oferecidos pela técnica são inúmeros.

Embora eu prefira livros impressos e tenha este é uma ótima maneira de economizar e ter o livro disponível sempre que precisar para referências.

Fica ai a dica! :)

Terceira reunião sobre arquitetura DotNetArchitects

2008-12-11T19:57:43+00:00

No próximo sábado (13/12/2008) , nosso grupo de arquitetura de software fará sua terceira reunião (nossa! como passou rápido...).

O local será o mesmo das outras vezes, na UNIP Jaguaré. Nesta semana o Giovanni irá falar um pouco a respeito de Domain Driven Design.

A participação é aberta e muito bem vinda. Quem ainda não mandou seus dados pode fazer pelo blog do Giovanni ou pelo grupo do Google onde também está disponível a pauta para próxima reunião.

Na última reunião falei sobre Scrum e o vídeo da apresentação está disponível aqui no blog e no site do grupo.

.NET Framework 4 Universe e paralelismo com LINQ

2008-12-03T09:21:48+00:00

Navegando nos links da microsoft, buscando a respeito de algumas features novas que vão estar disponíveis a partir do .net framework 4.0 encontrei duas coisas especialmente interessantes que merecem ser comentadas e linkadas.

Na edição deste ano do PDC foi entregue aos participantes um poster gigante com as novidades que devem vir para próxima versão do framework que deve sair ano que vem. O poster pode ser baixado por este link no blog do Brad Adams. Existe também uma versão estilo google maps onde você pode dar zoom e visualizar no browser com mais facilidade do que o faria em uma imagem gigante.

Antes de chegar a este link do poster assisti um webcast muito legal feito pelo Daniel Moth (Microsoft UK Developer) a respeito de paralelismo em queries LINQ. Hoje, quando rodamos software feito em .NET em em hardware multi-processado não conseguimos obter todo o benefício da utilização de multi processamento.

Com Parallel LINQ (ou PLINQ para facilitar) será possível tirar vantagem de todas as CPUs disponíveis no equipamento para diminuir drasticamente o tempo de processamento. Na demo feita pelo Daniel o ganho ficou em torno de 50%. A melhor parte disto é que quase nenhum código é necessário para obter essas melhorias. Se você ainda não viu nada a respeito de Paralelismo vale a pena dar uma conferida no vídeo.

Vou deixar também aqui alguns outros links complementares que eu peguei deste post no blog do Carlos Hulot:

mms://wm.microsoft.com/ms/uk/msdn/nuggets/PFX_TourOfSamples_Moth.wmv - MMS Vídeo

mms://wm.microsoft.com/ms/uk/msdn/nuggets/PFX_ParallelClass_Moth.wmv - MMS Vídeo

Mais referências oficiais:

http://msdn.microsoft.com/en-us/concurrency/default.aspx - Página oficial Microsoft sobre computação paralela

http://blogs.msdn.com/pfxteam/ - Blog do time de desenvolvimento de Paralelismo

Vídeo da segunda reunião DotNetArchitects com minha apresentação online

2008-11-27T23:44:09+00:00

Conforme prometido, o Victor disponibilizou pra gente o vídeo e o Giovanni já colocou no Google vídeos pra galera e publicou no site do grupo.

De qualquer forma, vou colocar aqui também pra fazer mais jabá!

Tá, tá, tá. Eu estava nervoso no começo, mas depois a coisa fluiu melhor. :)

Críticas como sempre, são bem vindas.

Espero que gostem!

Práticas ágeis são consistentes e replicáveis ao longo do tempo?

2008-11-27T22:43:14+00:00

Que as práticas ágeis funcionam, são gostosas de trabalhar e melhoram de uma forma geral o ciclo de desenvolvimento de software nós já sabemos. No entanto, existe uma dúvida: aplicar essas práticas de forma crescente, continua e de maneira comercial é possível?

Pergunto isso, pois aqui no Brasil ainda não temos nenhum grande case (que eu conheça pelo menos) de empresas prestadora de serviços (as famosas consultorias) que tenham investido nesse modelo durante tempo o suficiente (aka bastante tempo) e tenham conseguido se consolidar mantendo dentro de toda a cadeia de consultores e projetos as mesmas práticas e cultura envolvidas na utilização de métodos ágeis.

O motivo para isso não ter acontecido, na minha opinião, é que agilidade é um hype recente e por conta disso as consultorias ainda não chegaram no momento de replicar esse conhecimento para muita gente e muito rápido. Esse conhecimento ainda está na cabeça de poucos e os projetos que estão sendo executados utilizando agilidade são coordenados por estes poucos.

Mesmo em empresas "de verdade" (costumo chamar assim empresas "não consultorias" onde TI é importante, mas não é o core business) ainda não tenho certeza se isso é possível. Sei que o pessoal da Globo.com obteve muito sucesso em disseminar as práticas em mais de dez equipes, mas isso aconteceu com bastante trabalho, muito coaching e depois de algum tempo. Não do dia para a noite. Não tinha como ser diferente. Nesse cenário (vou me dar a liberdade de falar uma possível bobagem) onde a equipe tem um tamanho fixo ou perto disso e a demanda é mais ou menos conhecida acredito que escalar agilidade e disseminar as práticas seja mais fácil. Mas e em um cenário onde essas informações não são conhecidas, como fazer?

Como vocês sabem, trabalho em uma consultoria de software e estamos procurando aplicar práticas ágeis no maior número de projetos que pudermos (e onde agilidade for a melhor estratégia). No entanto, estamos indo com responsabilidade, pois senão de ágil só vamos levar o nome e nada da cultura. Por conta disso, esse movimento ainda não está em seu ápice de maturidade e poucos projetos (em relação ao todo que a empresa executa) estão utilizando dessas práticas. Contudo, a demanda por essas práticas está aumentando de uma maneira gigantesca e em algum momento a cultura e as práticas vão se perder se nada for feito a respeito.

Em resumo, temos um cenário onde a demanda não é conhecida nem de perto, as pessoas que farão parte dos novos projetos também não são conhecidas (pelo menos a maioria) e o tamanho das equipes e requisitos não são sabidos. Ai volto para pergunta inicial: como escalar e ainda assim obter consistência com agilidade em um curto espaço de tempo? Tenho certeza que não existe resposta mágica para essa pergunta.

É por isso que estou iniciando uma pesquisa não focada em agilidade e nem em aspectos técnicos, mas sim em um assunto que eu pouco vi comentado nas minhas leituras: capacitação de equipes ágeis. Ok, ok, ok...vocês vão me dizer que tá cheio de gente por ai que ministra cursos de capacitação de equipes em Scrum, XP, etc. Só que quando falo de capacitação, não estou falando em dar um treinamento de dezesseis horas para uma equipe e deixar a bola rolar. Isso, apesar de fundamental, está longe de ser suficiente.

Para inciar o estudo, estou me apoiando na experiência adquirida pela Toyota com a utilização do método de Instrução de trabalho e que está disponível em diversas literaturas onde cada um dos operários da linha de produção é um instrutor em potencial. É desse tipo de capacitação que estou falando. Executar um processo detalhado e peculiar (como são as metodologias ágeis) com a mesma precisão e qualidade em todas as pontas. Independente de gestão, equipe e localidade. Compartilhar os mesmos principíos desde o estagiário até o último nível da gestão. Para atingir esse objetivo é necessário aplicar um esforço brutal em treinamento e capacitação para que, na eventualidade, seja possível formar uma nova equipe treinada e preparada rapidamente.

Portanto, se alguém tiver experiência ou conhecimento de referências sobre esse assunto peço encarecidamente que compartilhe comigo (e com todos os leitores do blog), pois tenho certeza que esse é um assunto que em breve vai dar bastante dor de cabeça para muita gente. A idéia não é ficar esperando sentado até que as práticas e o nome se deteriorem pelo mau uso, mas fazer algo a respeito.

Conforme eu for avançando vou compartilhar minhas descobertas e experiências com vocês. Me desejem boa sorte. :)

Retrospective: 2º reunião DotNetArchitects

2008-11-24T18:59:24+00:00

Pronto...agora com um pouco mais de tempo posso comentar a respeito da nossa segunda reunião que aconteceu no último sábado dia 22/11 novamente nas instalações da UNIP Jaguaré.

Nessa reunião colocamos em prática o formato que haviamos combinado onde teriamos: uma apresentação de 30 minutos com tema relacionado a alguma experiência dos membros do grupo, discussão a respeito do assunto e por último pontos que surgiram por email e que o grupo deveria discutir a respeito.

A apresentação foi feita por mim e foi a respeito de como estamos adotando metodologias ageis em nossos projetos aqui na Stefanini. Poucos membros do grupo tiveram algum contato anterior com Scrum então a recepção do assunto foi muito boa (pelo menos foi o que pareceu pra mim...rs). Quem não conhecia ficou bastante interessado pelo assunto e desconfio que em breve iremos ter novos relatos a respeito deste assunto. Acho que consegui passar a mensagem durante a reunião, mas vale reforçar que quem precisar de apoio pode contar comigo além dos outros canais já existentes na comunidades.

Um ponto interessante é que a apresentação e toda a reunião foram gravadas em aúdio e vídeo. Como foi a primeira vez que eu fiz uma apresentação gravada foi um pouco estranho no começo usar o microfone "à lá Big Brother", mas depois fiquei tranquilo e correu tudo bem. Assim que os vídeos estiverem disponíveis pra download disponibilizo o link por aqui.

Depois da discussão conversamos a respeito de algumas pendências que o grupo tinha e ficaram decididos os seguintes pontos:

O site do grupo será, pelo menos até que não sirva mais, baseado no BlogEngine.NET que inclusive já está no ar;
O período entre reuniões foi encurtado e agora acontecerão a cada três semanas sendo a próxima no dia 13/12;
O tempo da apresentação inicial aumentou pra uma hora (os trinta minutos ficaram bem apertados e eu acabei estourando na minha apresentação) e o Giovanni vai falar sobre DDD;

Por último, mas nao menos importante, tivemos o nosso almoço! Como o grupo ainda está se formando e as pessoas não se conhecem muito foi bem legal e pudemos conversar a respeito de diversos assuntos relacionados e não relacionados a tecnologia.

O pessoal tirou algumas fotos, mas ningúem publicou ainda. Quando publicarem eu faço o link aqui também.

Em resumo a reunião foi EXCELENTE e o grupo promete bastante!

EDIT: Sabia que estava esquecendo algo quando postei. Eu gostaria de agradecer ao Vitor e Valdir e todas as outras pessoas da UNIP por sediar nossos encontros e pela excelente infra-estrutura e trabalho que possibilitaram a gravação deste encontro. Muito obrigado!

Slides apresentação "Encontros e desencontros na adoção de Scrum"

2008-11-22T23:19:15+00:00

Conforme eu havia prometido, estou publicando os slides que utilizei na apresentação de hoje de manhã na reunião do DotNetArchitects. Apesar de ter estourado no tempo (calculei mau...rs...) foi bem legal (deu pra gravar!) e tão logo o audio e vídeo estejam disponíveis eu posto aqui também.

ApresentaçÎÎo Scrum DotNetArchitects from Antonio Zegunis

Na sequência vou escrever outro post com minhas impressões a respeito da reunião.

Arregace as mangas - Liberte o seu espirito empreendedor: Resenha

2008-11-18T23:19:57+00:00

Recentemente por meio de uma indicação de um colega na lista Scrum-BR adquiri no Submarino o pequeno livro de 140 páginas "Arregace as mangas: Liberte seu espirito empreendedor" dos autores Fernandos Jucá e Max Gehringer. O livro custou um pouquinho menos de R$30,00 e no dia seguinte a minha compra já estava em casa!

O livro foi escrito a partir de uma série de emails trocados entre os autores a respeito de diversas discussões sobre empreendedorismo. No entanto, no final das contas o formato final ficou sem alterações então todos os tópicos abordados sobre o assunto seguem um esquema de conversação e não uma narrativa tradicional. Essa característica da um aspecto diferente e bem legal ao livro tornando a leitura bem fácil e descontraida.

Fernando Jucá, desde o começo de sua carreira foi empreendedor logo não é de se estranhar que escreva um livro a respeito do assunto. Max Gehringer por outro lado, nunca foi do tipo empreendedor que tem seu próprio negócio, mas sempre foi um excelente empregado. Esse lance de ser empreendedor e ter seu próprio negócio é um dos temas abordados no livro. Max conta que apesar de nunca ter investido em seu próprio negócio obteve muito sucesso em sua carreira sendo um intra-empreendedor que é o termo utilizado para definir o empregado que trabalha para a empresa de seu patrão como se fosse sua. Este não é o primeiro lugar onde vejo falarem que esse é o novo perfil de sucesso do futuro.

Antigamente, o funcionário padrão que entrava as 8:00AM e saia as 17:00PM tinha bastante espaço no mercado e possibilidades grandes de crescer dentro da empresa, mas hoje em dia isso não é mais suficiente. As empresas estão trabalhando mais enxutas, com menos margem de manobra e em busca de mais eficiência. Sendo assim, as pessoas que tiverem esse espirito intra-empreendedor tem muito mais possibilidades de crescer profissionalmente.

Um outro tópico do livro que vale destacar é aquele papo antigo de "Ele venceu por seus próprios esforços" ou "Ele conquistou tudo sozinho". Isso não é verdade! De acordo com os autores (e eu tenho que concordar) ninguém consegue vencer sozinho na vida. Principalmente um empresário, pois ele depende de fornecedores, de empregados, de clientes e de todos os outros que estão diretamente ou não ligados a sua atividade. Portanto é importantíssimo saber lidar com toda a rede de pessoas envolvidas com sua empresa para obter sucesso.

Eu não conhecia os autores, mas já descobri que existem diversos outros livros deles e que Max Gerhinger escreve pra Exame e participa de programas de rádio além de palestrar a respeito de liderança e aspectos de administração. Assim que puder, com certeza vou atrás de mais livros deles, pois apesar de não apresentarem nada de novo (e essa não é a idéia, de acordo com eles próprios) eles tem diversas sacadas bem interessantes e que com certeza agregam para aqueles que pensam ou já pensaram em deixar de trabalhar para os outros.

Search engine optimization: boas práticas e dicas

2008-11-18T22:42:51+00:00

Nos últimos dias, no meio das minhas feeds apareceram dois posts super interessantes a respeito de práticas para SEO que eu gostaria de compartilhar com vocês.

O primeiro post veio do blog Desenvolvimento para Web do Tárcio Zemel e apresenta o SEO Starter Guide publicado pelo Google com diversas dicas de como utilizar as tags HTML para melhor posicionar e organizar seu site.

O outro post que é do mesmo blog passa diversas dicas para para otimizar o seu a instalação do seu Wordpress e plugins com o mesmo objetivo: SEO.

Desde que fiz a minha própria instalação tenho na minha lista de pendências ir atrás dessas alterações pra melhorar o posicionamento e acesso ao meu blog, mas infelizmente ainda não tive tempo suficiente. Quem sabe depois de post eu arrume tempo e faça as alterações necessárias, né?

Espero que aproveitem as dicas!

DotNetArchitects - Próximo Encontro

2008-11-18T20:14:15+00:00

Para quem acompanha meu blog e ainda não sabe do que se trata nosso grupo pode ver informações a respeito dele aqui, aqui e aqui. Nossa...quanto aqui!

Para quem já sabe o que é mais não se juntou ainda ou não acompanha, faço um convite a conhecer através do nosso ~~não-muito-joia-ainda~~ site e se juntar também ao nosso grupo do Google onde algumas discussões bem legais já foram iniciadas.

Desde a primeira reunião do grupo combinamos que em todas as nossas reuniões alguém iria fazer uma apresentação para que posteriormente o grupo discutisse o assunto e a primeira apresentação sou eu quem vai fazer. A idéia não é dar uma aula ou falar como "o expert" do assunto, mas tentar passar experiências interessantes para todos.

Esta primeira apresentação vai ser a respeito de Scrum e como estamos utilizamos dentro da nossa equipe.

Na sequência da apresentação eu disponibilizo os slides aqui para quem não pôde ir. É possível que consigamos gravar a reunião. Se der certo, disponibilizo também por aqui.

Junte-se a nós! :)

CMMI or Agile: Are we really falling?

2008-11-15T13:00:33+00:00

Com a recente publicação do report "CMMI or Agile: Why not embrace both!" pelo SEI muito flame-war tem sido gerado nos blogs do mundo da agilidade e nas listas de discussões sobre esse assunto. Alguns posts, não sei se motivados por esse report ou não, inclusive clamam que o início da queda dos processos ágeis e do movimento ágil começou.

Lendo a opinião das pessoas, é possível separar em dois grupos distintos os tipos de reclamação:

Os "early-adopters" de Agile que acreditam que, por causa da chegada de Agile ao main stream aqui no Brasil, as práticas ficaram(ão) deturpadas e distorcidas e que agora todo mundo diz que é ágil, mas na prática,de acordo com a opinião desses mesmos "early-adopters" não são;
As pessoas que não acreditam que seja possível a co-existência entre CMMI e Agile e recusam-se a acreditar que isso possa trazer benefício algum;

Eu discordo dessas duas linhas de pensamentos e acredito que, mais que nunca, agora é que a coisa principalmente aqui no Brasil tende a melhorar.

Neste post, James Shore conta que antigamente ele era chamado para introduzir agilidade nos ambientes corporativos (e da a entender que essa época era boa). No entanto, hoje ele é chamado para ajudar a corrigir equipes "so called agile" que na verdade de ágil não tem nada. Bom... os tempos mudaram! É pouco provável que essa época onde a iniciação em agilidade deveria ser feita por um dos agile-gurus durasse pra sempre.

Como eu disse acima, o movimento chegou ao mainstream, mas isso só aconteceu porque quem iniciou esse movimento assim o quis. Agile veio do povo para o povo e isso agora incomoda muita gente. Hoje, quem quiser manter o título de master-introduzidor-de-agilidade-e-coaching vai ter que ralar e se ajustar as novas demandas.

Ainda comentando a respeito do primeiro grupo de opiniões, assim como a bíblia (é, aquela sagrada a respeito de Deus) e de acordo com os próprios autores de alguns livros conhecidos como referência (Scott Ambler em Agile Modeling e Ken Schwaber em Project Management with Scrum, por exemplo), práticas ágeis são apenas o que o próprio nome diz: práticas!

Como não são um how-to detalhado que você deve aplicar em todas as ocasiões e muitas vezes bastante abstratas são passíveis de interpretação. Sendo assim, como alguém pode dizer se você é ou não ágil? Se as práticas que você aplica estão trazendo resultados satisfatórios qual o problema em se referir ao termo agilidade? Está acontecendo a mesma coisa que acontece com alguns usuários de Linux e alguns participantes de projetos open-source: as pessoas estão se apegando demais aos termos e títulos e deixando de lado realmente o que o movimento prega. Parece ciúmes.

Movendo agora o foco para o segundo grupo de reclamantes, acredito que afirmar que CMMI é incapaz de trazer benefícios para as práticas ágeis é no mínimo uma contradição visto que um dos princípios básicos de agile é adaptação. Sempre quando alguém fala a respeito de como iniciar com metodologias ágeis uma das primeiras recomendações que ouço é "Não tente mudar o processo antes de utilizar ele da forma padrão. Experimente e depois decida se é necessário fazer alterações". Olha lá! Mais um motivo para não fazer essa afirmação de que nenhum benefício pode ser colhido dessa co-existência. Como alguém pode afirmar que não vai dar certo se esse report foi uma das primeiras menções (se não a primeira) a respeito dessa co-existência e nada concreto ainda foi gerado? É a mesma coisa que dizer que não gosta de brocólis sem nunca antes ter provado.

Não sou expert em CMMI, tão pouco em Agile. No entanto, se verificarmos a origem do CMM e como a transformação ocorreu para o CMMI é possível entender porque as práticas são tão distoantes. O CMM teve origem no departamento de defesa dos Estados Unidos. Eles precisavam de um modelo que pudesse garantir que o software funcionando em um avião militar não parasse de funcionar no meio de um vôo. Hmm... não precisamos pensar muito pra concluir que antes de testar um treco desses em produção (guerra?) ou em homologação (vôo de treinamento?) seriam necessários muitos testes para garantir que os milhares de dólares que essas belezinhas custam não fossem jogados no buraco; sem falar na vidas dos pilotos.

Dessa forma, acredito que essa abordagem extremamente pesada, com longa duração e diversas exigências de verificação e validação em diversos níveis hierarquicos, de fato, não parece a pior opção pra esse cenário.

São duas abordagens diferentes e que devem ser usadas em cenários diferentes. O perigo é conhecer uma ferramenta só (martelo) e sair martelando tudo que encontrar pela frente até quando o alvo não é um prego, mas sim um parafuso.

Em resumo e para conluir (já escrevi muita coisa...) acredito que é cedo pra afirmar qualquer coisa e que não devemos nos opor tão radicalmente as mudanças (como o próprio manifesto prega). Se essas mudanças tanto no aspecto da ascensão de Agile ao mainstream quanto das mudanças oriundas da co-existência com CMMI forem pra melhor, vão permanecer. Se forem para pior, com certeza o mercado logo, logo esquece... e se não esquecer cada um pode sempre criar seu próprio mundo onde tudo é bonito e belo! :)

Dando as caras

2008-11-11T21:23:27+00:00

Post só pra dizer que estou vivo!

Esse último mês tem sido bastante complicado (fim de projeto) e nós últimos dias não consegui parar pra postar nada. Odeio ficar sem postar porque gosto de escrever, mas nos próximos dias se tudo der certo coloco a pauta que tenho guardada pra rodar e os posts voltam a seu ritmo.

Enquanto isso, acompanhem um pouco das novidades no link do nosso recém criado grupo de arquitetura: http://dotnetarchitects.net/

Fiquem ligados!

Design para quem não é Designer: Resenha

2008-11-03T21:15:02+00:00

Esta resenha é a respeito de um livro com um assunto um pouquinho diferente do que estou acostumado a ler: design visual. Já há algum tempo, tenho algumas idéias de produtos/sistemas/serviços que eu poderia construir e lançar no mercado. No entanto, de nada adianta ter um bom produto se ele não tiver uma cara apresentável e que prenda a atenção do consumidor. Como não conheço ninguém que topasse fazer esse tipo de trabalho só por hobbie, decidi estudar um pouco por conta própria.

Sendo assim, há algumas semanas, terminei de ler este livro de 144 páginas que comprei na Livraria Cultura por R$40,00. O livro foi escrito por uma autora americana chamada Robin Williams que além deste, escreveu uma série de livros relacionados a design.

Eu não tenho pretensão nenhuma de mudar de área e me especializar em arte gráfica ou coisas do tipo, mas este livro me chamou bastante a atenção. Além das idéias que relatei acima, construir um produto ou uma marca é uma coisa muito complicada, mas como alguns outros colegas sempre dizem e foi dito também no livro do Chad Fowler: meu nome é minha marca. Portanto, tudo que acompanhar meu nome além de qualidade no conteúdo e veracidade nas informações pode ser melhorado se possuir um bom visual.

O Livro explica de uma maneira bem leve e didática (procurei outros livros sobre o assunto, mas nenhum me prendeu tanto quando este) os quatro princípios básicos do design: Alinhamento, Proximidade, Contraste e Repetição. Todas as peças publicitárias e materiais relacionados a publicidade e design possuem esses 4 princípios aplicados e fica muito mais interessante olhar e avaliar os trabalhos do outros (e o meu próprio) quando se sabe o conceito por trás da coisa.

Além dos princípios o livro também apresenta uma boa introdução a respeito de tipografia e uso de tipos na escrita. Estudando um pouco a respeito deste assunto fica claro porque algumas fontes são melhores para leitura do que outras e porque algumas fontes bizarras são empregadas em nos usos mais diversos e por mais incrível que pareça ainda consigam produzir um bom resultado.

Durante todo o livro, a autora apresenta diversos exemplos "Antes" da aplicação dos princípios básicos e "Depois". São várias figuras que vão desde papéis de carta até cartões de visita e folhetos de anúncio. É impressionante como pequenas alterações no layout de um texto conseguem mudar totalmente a cara e a impressão que o documento passa.

O exemplinho bobo que fiz acima é apenas para ilustrar como o mero fato de agrupar informações relacionadas já garante uma aparência mais satisfatória a um cartão de visitas.

Esse é um livro que eu recomendaria a todos que tenham interesse em aprender um pouco a respeito de conceitos de design visual e também a quem se chama de web-designer porque consegue fazer páginas e sites bonitinhos, mas nunca procurou entender realmente o porque das coisas.

Leitura recomendadissíma!

Primeira reunião do Grupo de Arquitetura

2008-10-28T09:12:51+00:00

Bão, sábado foi a primeira reunião do grupo de arquitetura que eu já havia postado a respeito.

Como o Giovanni já blogou sobre o que rolou na reunião não vale repetir tudo aqui, mas sim linkar para o post dele.

A reunião foi excelente, muito divertida e de um ótimo nível. Felizmente conseguimos reunir um grupo que não chegava em acordos sempre e isso é fundamental para crescermos.

Os interessados em entrar no grupo podem me mandar email, comentar aqui ou então postar no próprio blog do Giovanni. "Você decide". :)

Download VS2010 + Framework 4.0 CTP

2008-10-28T09:08:01+00:00

Post rápido! Saiu o link para o download do Visual Studio 2010 e Framework 4.0. Ambos em CTP.

O Download tem 7gb e este é o link. Comecei a baixar faz pouco tempo e quando terminar e (conseguir) testar posto minhas impressões.

Mas já da pra adiantar que tem bastante novidades: o Israel Aece blogou sobre algumas e eu já havia postado também alguns links aqui.

Go!

Falha nossa

2008-10-23T20:06:36+00:00

Gostaria de pedir desculpas aos leitores que utilizam o Internet Explorer, pois desde que publiquei este post o blog ficou com o layout todo deformado neste navegador. Isso aconteceu, pois tinha escrito originalmente o post no Word e na hora de colar no blog colei errado e um monte de tags oriundas do Word vieram parar no meio do post bagunçando todo o HTML do blog.

Como uso praticamente só o Mozilla só fui perceber esse erro hoje. Já arrumei e tudo deve ter voltado ao normal. Por favor, me avisem se ainda tiver algum problema. :)

Visual Studio 2010: Diversas novidades

2008-10-22T18:43:24+00:00

Este é um post rápido. O Carlos Hulot publicou há pouco em seu blog links para diversos vídeos e informações a respeito da nova plataforma da linha Visual Studio e Team Foundation Server da Microsoft.

Comecei a ver os vídeos agora e estou baixando ainda outros, mas está bem interessante. Vale a pena dar uma olhada.

Segue o link: http://blogs.msdn.com/hulot/archive/2008/10/22/application-lifecycle-management-vsts2010.aspx

Contratando novamente!

2008-10-22T11:49:43+00:00

Mais uma vez estamos contratando. Duas vezes em dois meses... estamos indo bem!

Vamos ao que interessa. Como dito no outro post, continuamos com Scrum e uma equipe enxuta (alguns sairam, pois não se encaixaram e outros entraram) de 12 pessoas distribuidas em três times pequenos e focados. Só que nessa vez não estamos atrás de desenvolvedores (mas se alguém tiver interesse, nunca desprezamos novos bons membros para a equipe), mas sim de um Database Aniquilator, conhecido também como DBA. :)

A fim de eliminar o desperdício de esforço e melhorar alguns processos descobrimos (antes tarde do que nunca) que alguém especialista em banco de dados, SQL Server principalmente, faz muita falta. No entanto o que precisamos não é alguém que apenas fique conectado como "sa" rodando scripts em produção. Precisamos de alguém que esteja em sintonia com as equipes de desenvolvimento e as apoie o tempo todo em desenvolvimento (dúvidas, organização e tuning), seja responsável pela saúde dos bancos de dados e nos ajude a criar uma política mais eficiente de integração, consistência de dados e deploy.

Somos uma equipe ágil e altamente entrosada onde todo mundo joga junto. Nossa equipe não é grande e cresce de maneira organizada e estruturada.

Sendo assim, o perfil de entusiasta é fundamental. Graduação, pós-graduação, mestrado e certificações não é o que estamos buscando. Portanto, não são um diferencial. Fazer apenas sua parte não é o suficiente. Como de costume, é necessário ter interesse em aprender e aplicar novas práticas, interagir com os membros da equipe e aceitar ser desafiado e questionado, pois é isso que faz com que nossa equipe cresca.

Nessa vaga, em especial, além das soft skills os conhecimento técnicos são extremamente importantes. Hoje, nossos bancos de dados são gerenciados por mim e alguns outros membros da equipe. Nós conhecemos alguma coisa de banco de dados, mas nossa especialidade é desenvolvimento, portanto no mínimo o candidato deve conhecer mais banco de dados do que a gente :). Especificando um pouco mais precisamos de conhecimentos em: replicação, segurança (roles, rules, etc), organização e distribuição de filegroups, pagefile, etc e SSIS. Experiência em shell, execução de scripts via batch e gerenciamento de instâncias e administração windows server também são necessárias.

Enfim, tudo que um bom projeto de software precisa no que diz respeito a banco de dados.

Estamos em São Paulo capital, na região de Pinheiros. A Contratação é como PJ e temos alguns benefícios.

Se você se interessou pela oportunidade email-me azegunis@stefanini.com.br.

Grupo de estudos sobre Arquitetura - 1ª Reunião

2008-10-21T10:52:02+00:00

Há alguns dias atrás o Giovanni Bassi trouxe a idéia pra comunidade de criar um grupo com o objetivo de discutir arquitetura de software nos moldes dos grupos ALT.NET e a idéia me interessou muito.

Enfim, a primeira reunião é sabado agora na UNIP da Marginal Pinheiros. Quem tiver interesse será muito bem vindo.

Os detalhes podem ser encontrados aqui no blog do Giovanni.

Boas práticas de engenharia podem influenciar a motivação?

2008-10-20T22:36:41+00:00

Hoje, como nunca, acredito que o mercado esteja cheio de profissionais ruins. Não digo somente no sentido técnico, mas principalmente em perfil (que ao meu ver é o mais importante); que faz um desenvolver correr atrás de estudar, procurar as melhores práticas de software e buscar melhorar seu trabalho. Motivação. Encontrar um profissional motivado que aceite críticas e procure crescer e agregar a equipe e empresa que pertence é raro, muito raro.

Existem diversos fatores que julgo influenciarem esse tipo de perfil: escassez de pessoas qualificadas, ofertas de trabalho em abundância, prostituição do mercado de trabalho, políticas falidas de recursos humanos, entre outros. Dependendo da nossa posição, poucos desses fatores são de nosso controle.

No entanto, nos últimos dias passei por uma experiência interessante e percebi que existe um ponto em especial que podemos controlar plenamente ou contribuir para evitar esse tipo de comportamento desinteressado: boas práticas de engenharia de software.

É impressionante como encorajar a aplicação de boas práticas de desenvolvimento de software pode transformar pessoas antes desinteressadas novamente em profissionais ativos e entusiasmados. Não é necessário ter as melhores ferramentas, utilizar a última tecnologia da moda ou o melhor processo de desenvolvimento. Na maioria das vezes basta que o líder incentive e apoie esse tipo de comportamento para obter bons resultados.

Mesmo que você não seja líder de equipe e que algumas pessoas o desencoragem com aquele papo de "não adianta tentar fazer X oy Y porque aqui isso não vai funcionar", não entre nessa onda. Procure incentivar as pessoas que estão ao seu redor a buscar a melhoria contínua e mesmo que todos não te ouçam não desista. Existem muitas empresas que valorizam profissionais com perfil arrojado e pró ativo.

Valorize-se!

Artigo a respeito de Scrum na revista MundoNET

2008-10-17T23:19:35+00:00

Essa semana saiu nas bancas a edição número 11 da revista MundoNET. A partir dessa edição comecei a participar com artigos e o primeiro "Scrum - Introdução a Agilidade" já foi publicado. :)

Fiquei muito feliz em poder participar e contribuir com minha experiência e espero que todos gostem também. Acho pouco provável que irei agradar a todos com o artigo, mas se gerar algum tipo de discussão já é válido. Afinal, é a partir de críticas e discussões que crescemos, não é mesmo?

Durante o tempo que estava escrevendo para a revista acabei dando uma esfriada aqui no blog, mas já estou me organizando melhor e devo postar com mais frequência daqui pra frente. É bem legal e bastante diferente escrever para revista e é uma experiência que eu ainda não tinha, mas gostei bastante!

Nessa edição tem outros dois artigos que, particularmente, achei bem legais a respeito de Flex com .NET e BI em projetos Web.

Vale a pena conferir!

My Job Went to India: Resenha

2008-10-13T22:55:02+00:00

Há uns três meses atrás, enquanto navegava pelos links que leio frequentemente, mesmo sem antes ter feito nenhuma dessas perguntas encontrei algo parecido com a resposta e esse livro fazia parte dela. Me interessei e comprei o livro.

Para variar, comprei na Livraria Cultura por R$64,84 e em umas duas semanas recebi o pequeno livro de 252 páginas em casa.

O autor, Chad Fowler (que não é parente do Martin Fowler), conta em 52 "mini-histórias" o que fazer para não perder seu emprego e da diversas dicas de como crescer tanto profissional quanto pessoalmente.

O livro foi escrito na época em que executar projetos offshore) era visto como a melhor e mais barata maneira de se construir projetos de software nos Estados Unidos. De acordo com Fowler, nesse época muitos programadores acabaram perdendo seus empregos para indianos do outro lado do mundo e cada vez mais achavam que os indianos estavam tirando seus empregos.

O que fazer para crescer na carreira profissional?

Como manter meu emprego?

Como posso melhorar profissional e pessoalmente?

Em um desses projetos o autor foi enviado pra India com a responsabilidade de abrir uma filial e contratar indianos para montarem a filial supostamente mais barata e eficiente. No entanto, gerenciar uma equipe a milhares de quilometros de distância não é fácil como parece (se é que parece). Durante todo o livro ele relata os obstáculos que existem em se montar uma operação desse tipo e porque essa forma de trabalho não vai deixar os americanos desempregados.

Ele descreve exemplos de como é importante trabalhar no marketing pessoal e não focar apenas na parte técnica, pois não adianta você ser o melhor técnico do mundo e não investir na comunicação para que as pessoas saibam o quão bom você é. Comunicação é fundamental.

Outro ponto que achei bastante interessante é que devemos aprender a falhar, tirar proveito disso e crescer. Não devemos nunca imaginar que estamos na crista da onda porque conhecemos uma tecnologia em especifico. Uma hora a onda passa e nós ficamos pra trás. É necessário que não deixemos que o rumo de nossas carreiras seja definido ao acaso, mas sim baseado em decisões concientes e estratégicas sempre de olho no mercado atual e nas mudanças que estão ocorrendo.

Além dos aspectos técnicos é também uma oportunidade de conhecer um poquinho a respeito da cultura de outro país e aprender como lidar com pessoas diferentes.

Enfim, este é um livro bastante amplo e ao mesmo tempo específico que com certeza vai abrir sua mente. Acredito que seja um dos melhores que já li e é uma leitura obrigatória pra quem quer crescer!

Nem tudo é relacional

2008-10-01T21:47:08+00:00

Esses dias me peguei pensando em um costume interessante que temos. Quando digo "nós", falo de min e das pessoas com as quais já trabalhei nesses 4 anos que atuo com .NET. Fomos acostumados, em se tratando de persistência em banco de dados, de sempre utilizar modelo relacional pra qualquer tipo de armazenamento de objeto. O problema é que nem sempre isso é necessário e acabamos perdendo ou tempo em codificação ou desempenho ou espaço em disco.

A idéia de banco de dados orientado a objetos sempre me agradou e acho uma pena não ter chegado ao mainstream. No entanto o conceito de armazenar o grafo todo de objetos é muito interessante em algumas situações. Vou usar um exemplo que talvez não seja o melhor, mas deve passar a idéia.

Imagine um cadastro de cliente com diversas entidades relacionadas: diversos endereços, vários telefones para contato, dependentes, etc.

Normalmente criaríamos uma tabela para cada uma das entidades e essas tabelas teriam uma referência (FK) para a tabela principal de clientes:

Se considerássemos que um endereço ou automóvel pudesse pertencer a mais de um cliente a coisa ficaria ainda mais complicada e teríamos que criar tabelas de relacionamento N:M.

Para que o exemplo seja útil, vamos considerar que nesse sistema não fosse possível efetuar pesquisas utilizando como filtro nenhuma dessas entidades (em um sistema real é óbvio que requisito é um absurdo) e só seria disponibilizada uma funcionalidade de busca por meio de código (id). Mesmo com esse requisito, como pensamos sempre em de forma relacional o caminho natural seria criar o modelo de dados acima e armazenar tudo bastante normalizado.

No entanto existe outra opção que em determinados casos é muito interessante. Guardar o objeto inteiro no banco.

Em .NET, por exemplo, bastaria criar um modelo simples de dados contendo o idCliente e um campo que armazene binário (varbinary em SQL), serializar o objeto e pronto.

public Cliente Consultar(int codigoCliente)
{
    //Recupera do DB
    byte[] clienteSerializado = DaoCliente.ConsultarPorCodigo(codigoCliente);
    //Devolve o objeto deserializado
    return this.DeserializarObjeto<Cliente>(clienteSerializado);
}

public void Salvar(Cliente novoCliente)
{
    //Serializa o objeto
    byte[] clienteSerializado = this.SerializarObjeto<Cliente>(novoCliente);
    //Guarda o cliente no DB
    DaoCliente.Inserir(novoCliente.Codigo, clienteSerializado);
}

private byte[] SerializarObjeto<T>(T objeto)
{
    MemoryStream ms = new MemoryStream();
    BinaryFormatter formatter = new BinaryFormatter();
    formatter.Serialize(ms, objeto);
    byte[] objetoSerializado = ms.ToArray();
    ms.Close();
    return objetoSerializado;
}

private T DeserializarObjeto<T>(byte[] objetoSerializado)
{
    MemoryStream ms = new MemoryStream();
    BinaryFormatter formatter = new BinaryFormatter();
    ms.Write(objetoSerializado, 0, objetoSerializado.Length);
    ms.Position = 0;
    return (T)formatter.Deserialize(ms);
}

Dessa maneira, sempre que precisarmos, já iremos ter o objeto completo e não seria necessário executar diversas instruções SQL ou stored procedures e muitas chamadas ao banco. Iriamos apenas executar uma chamada que nos retornaria o objeto completo e pronto para uso.

Essa é uma solução diferente e que pode ser útil em alguns cenários, principalmente se você não utiliza nenhum framework ORM. Contudo, é importante verificar todos os requisitos com bastante cuidado, com essa solução corremos o risco de ficar com dados desatualizados e perdemos a possibilidade de efetuar buscas por campos que estejam dentro dos objetos armazenados.

Acho muito legal encontrarmos formas diferentes de fazer as mesmas coisas que estamos habituados. É uma maneira muito eficiente de aprendizado e conhecimento das nossas ferramentas.

O que você acha?

Editado: sem saber, acabei descrevendo o pattern Serialized Lob já catalogo pelo Fowler em seu livro PoEAA. O Bruno achou e comentou o post colocando este link. Valeu! :D

Novo Microsoft Architecture Guide lançado

2008-09-24T10:49:12+00:00

Lá atrás, em 2002, a Microsoft lançou a primeira versão da sua arquitetura de referência para os cenários mais comuns de aplicações corporativas.

Esse é um documento, que apesar de antigo, é bastante interessante e ainda atual na maioria dos aspectos. Eu descobri esse documento cerca de uns 1 ano e meio atrás quando procurava melhores práticas para aplicar no primeiro sistema pelo qual eu seria responsável.

Sempre achei uma pena o fato de eles não manterem esse documento atualizado. Talvez isso acontecesse, pois é sempre complicado falar a respeito de arquiteturas de referência já que cada caso é um caso.

No entanto, pra nossa felicidade, eles lançaram uma nova versão esse mês e está disponível através deste link no Codeplex.

O documento apresenta quais decisões tomar e porque toma-las em uma série de cenários. Desde aplicações desktop até aplicações web com SOA e RIA.

Ainda não tive tempo de ir a fundo no documento, mas parece estar bastante atualizado.

Há algum tempo atrás, eu procurava saber porque raios alguém construiria uma aplicação utilizando WCF/Remoting/Web Services se essa aplicação não teria seus componentes de negócio reutilizados. Nunca entendi isso e achava um absurdo a Microsoft não disponibilizar nenhum "guia" (eu nunca achei, pelo menos) que dissesse quando devo distribuir as camadas de uma aplicação fisicamente e quando não. Infelizmente algumas coisas nós acabamos aprendendo só depois de aplicar e apanhar um pouco.

Nesse documento, pelo menos este ponto a Microsoft esclareceu e isso já é suficiente pra me deixar bastante feliz.

Esse documento não vai evitar que nós, desenvolvedores, cometamos erros, mas acredito que é muito importante os fornecedores de plataformas e tecnologias grandes como .NET se pronunciarem e fornecerem guias, mesmo que simples e com uma visão bem macro, para que as pessoas não fiquem perdidas e cometam erros demais em seus sistemas.

Ponto pra Microsoft.

Faça o que tem que ser feito

2008-09-19T20:03:04+00:00

Na área de TI, principalmente em desenvolvimento, o que eu mais vejo são pessoas que estão trabalhando simplesmente por estar. Este é um assunto que, inclusive, eu já havia comentado aqui mesmo no blog. São poucas as pessoas que procuram fazer seu trabalho da melhor maneira possível e menor ainda é a quantidade de pessoas que usam de seu tempo livre para estudar e encontrar maneiras de fazer seu trabalho melhor.

Se você não é uma dessas pessoas que apenas empurra seu trabalho com a barriga, existem algumas coisas que você pode fazer para ter mais chances de ser bem sucedido durante sua carreira profissional.

Não são raras as vezes em que trabalhamos em uma empresa grande e não passamos de um número. Essa é uma situação relativamente ruim e pessoas ambiciosas (no bom sentido da palavra se é que tem um ruim) não se sentem confortáveis nessa posição. No entanto, ganhar visibilidade no meio de tanta gente não é uma coisa muito fácil e pode demorar muito tempo. E não é só questão de visibilidade, mas também de procurar um sentido para aquilo que você se dedica diariamente. Dependendo do tamanho da empresa e da posição as vezes não temos condições nem de dizer o que realmente a empresa faz.

Uma das formas de ganhar visibilidade e reconhecimento dentro da empresa é fazer alguma coisa que impacte positivamente no resultado da empresa dela. Seja esse resultado financeiro, operacional ou de qualquer outro tipo.

O problema é que é muito complicado, como um mero desenvolvedor em uma grande organização, fazer alguma coisa sozinho que faça esse tipo de diferença.

"Como vou fazer isso?"

Geralmente toda equipe de desenvolvimento tem um gerente (independentemente de ser um gerente tradicional ou não) ou algum tipo de chefe. Esse gerente tem problemas ou objetivos a cumprir e se utiliza de sua equipe (se não utiliza, deveria) para resolve-los. Em uma empresa organizada, esse problema que ele tem que resolver deve estar alinhado com os objetivos da empresa. Sendo assim, como membro do time de desenvolvimento, você deve descobrir qual o problema que seu time deve resolver e trabalhar o máximo que puder para resolve-lo ou pelo menos ajudar seu time a faze-lo. Dessa maneira você estará ajudando seu time e de brinde seu gerente, pois o problema que ele tinha já não exisitirá mais.

Nesse momento, somente pelo fato de trabalhar pela equipe e cumprir um objetivo que não é pessoal, você já deve se sentir bem.

Se seu gerente também estiver alinhado com esse pensamento e estiver tentando resolver o problema do chefe dele, com essa sucessão de acontecimentos você vai acabar resolvendo ou contribuindo para a solução do problema do chefe do seu chefe. E assim a coisa vai até o topo da empresa...

"Mas ai meu gerente vai pegar todo meu crédito? Nem a pau!"

É, podemos dizer que ele irá, mas esse é o trabalho dele. Como gerente, ele deve utilizar-se das pessoas corretas (uma dessas pessoas é você) nos lugares corretos para atingir um objetivo. Quando você menos esperar, você estará contribuindo para um movimento que provavelmente fará a diferença no resultado da empresa. Dessa forma, seu chefe será reconhecido e conforme as coisas forem avançando isso irá refletir em você também.

Não podemos esquecer, que acima de tudo, estamos trabalhando para uma empresa. Essa empresa tem objetivos a serem cumpridos. É muito fácil falar que devemos estar alinhados com esses objetivos. Difícil é realmente estar alinhado, mas faz parte do nosso trabalho tentar.

Se a organização conseguir passar esses objetivos para seus funcionarios e estes se comprometerem realmente para com a equipe inevitavelmente todos irão ganhar. Espirito de equipe é fundamental!

DDD no Entity Framework

2008-09-11T02:15:18+00:00

Essa informação é não a mais nova do mundo (saiu há 3 meses atrás), mas da mesma maneira que passou desapercebido pra min e pro Giovanni Bassi (que foi onde eu vi hoje), pode ter passado pra muita gente e eu acho mais do que legítimo divulgar.

Depois do oba-oba que a comunidade fez contra o Entity Framework que acabou saindo meio mal acabado e ainda totalmente focado em banco de dados sem suporte a PI para POCOs no SP1 a Microsoft finalmente deu uma dentro.

Eles convidaram Eric Evans (criador do domain-driven design), Martin Fowler (não preciso dizer quem é, né?), Jimmy Nilsson (praticante de DDD com .NET que escreveu um ótimo livro), Stephen Forte e Pavel Hruby para formar um conselho com o objetivo de palpitar a respeito de como o Entity Framework deveria ser remodelado.

Com esse pessoal todo envolvido e mais algumas coisas que o pessoal anda soltando no blog do EF, boto fé que vem coisa boa ai pela frente!

A "notícia" pode ser vista com mais detalhes neste link.

Inspeção e adaptação: a força dos processos ágeis

2008-09-08T07:13:31+00:00

Até começarmos a utilizar Scrum eu nunca havia entendido direito o mecanismo chamado de inspeção e adaptação. Toda a minha experiência com desenvolvimento de software até então era com utilização de processos cascata em caixinha. Eu chamo de processos em caixinha aqueles processos utilizados em grandes consultorias geralmente mantidos por uma equipe de tamanho razoavel que tem como principal responsabilidade escrever e gerenciar diversos templates de documentos. O interessante é que quase nunca as pessoas sabem porque devem preencher esses documentos e na maioria das vezes nem as pessoas que escrevem os templates sabem pra que eles servem.

Nessa época eu sempre me perguntava se era realmente necessário documentar nos mínimos detalhes tudo que era feito dentro do projeto e, quando eu falo de documentar não me refiro somente a artefatos intimamente ligados com código como especificações e modelos, mas também a extensas planilhas de rastreabilidade, longos emails com cópia pra Deus e o mundo entre outros tipos de documentos que completam essa lista.

No final, esses documentos eram todos utilizados pra poder garantir os selos de ISO e CMM que a consultoria buscava ou já mantinha.

No entanto, nunca nenhum desses milhares de documentos que só enchiam o Source Control ajudou algúem em alguma ocasião de problema. Muito pelo contrário: as vezes o cidadão tomava uma bela chamada porque não mantinha os malditos documentos atualizados. Também pudera, diversos documentos espalhados e sem nenhuma utilidade prática. Quem é que tem paciência de manter atualizado um troço desses?

Em uma dessas empresas que trabalhei, numa determinada época, os desenvolvedores tiveram que estudar a respeito de Six Sigma, pois uma auditoria estava próxima e todos deveriam estar com as respostas prontas na ponta da lingua. Foi ai que eu tive o primeiro contato com o mecanismo que intitula este post. Ai foi só ligar as peças. Todos esses documentos que a equipe gerava deveriam servir como base histórica para consulta a fim de melhorar futuras estimativas e antecipar problemas, ou seja, inspecionar e adaptar!

O problema é que apesar de termos diversos documento e dos mantenedores de processo apostarem suas vidas quando diziam que as metodologias de caixinha utilizavam deste mecanismo, nunca faziamos nada parecido com uma sprint retrospective, por exemplo. Este é o grande ponto falho de modelos cascata. Como tudo é feito de uma vez, fase a fase, quando percebemos que alguma coisa foi mal (geralmente nas últimas semanas de projeto) já é muito tarde pra correr atrás do problema. Tudo o que sobra então é procurar quem culpar.

Inspeção e adaptação é um dos mecanismos mais importantes e úteis que você pode utilizar pra melhorar seu trabalho. E é ai que a força dos processos ágeis está. E não são necessários documentos para isso. Basta comunicação fluente e contínua entre os membros da equipe.

Os processos agéis são a evolução do modelo cascata. No entanto essa retroalimentação do processo é algo que foi deixada de lado.

Modelos ágeis nos forçam a olhar pra trás frequentemente para ver onde erramos e onde acertamos. Dentro do Scrum nós temos pelo menos dois momentos para realizar a inspeção e adaptação: Daily Meeting e Sprint Retrospective. Essa primeira reunião executa este processo de maneira menos formal, mas possibilita que todos os membros do time sincronizem seus trabalhos e evitem cometer erros que outros membros já cometeram. Isso acontece naturalmente na conversa diária de quinze minutos. Já no Sprint Retrospective, que no meu caso acontece de duas em duas semanas, todos estão focados para identificar o que não foi legal e poder corrigir e continuar executando o que estiver dando certo.

Contudo, existe uma coisa que pode prejudicar essa retroalimentação: a incapacidade dos membros do time entenderem que as críticas não são pessoais, mas para críticas as atitudes que levam a falha e ao erro. É importantíssimo que todos no time saibam aceitar quando erraram e procurar melhorar, pois só um time que não deixa de se criticar a cada momento consegue ter pleno sucesso. A crítica é a base para o crescimento.

E funciona porque o processo é executado todo o tempo, e desvios são encontrados quando ainda há tempo de corrigi-los. É o puro exercício do aprendizado contínuo!

Eba! Primeira certificação Microsoft!

2008-09-03T20:56:05+00:00

Esse é um post mais pessoal do que técnico ou com contribuição profissional. Ontem fiz minha primeira prova de certificação microsoft, a 70-536, e passei! :D

O engraçado foi que, na metade da prova, eu tinha certeza que já tinha reprovado. A prova tem duração de 3 horas e 40 questões. Em menos de 30 minutos estava prontinha!

O fato de achar que tinha reprovado não foi porque não estudei (eu não estudei mesmo), mas sim pelo fato da prova não cobrar nada que seja realmente útil ou do dia-a-dia. Fiquei decepcionado com o conteúdo da prova. Foram muitas questões a respeito de COM+ que na minha opinião já não tem mais nada a ver com a atualidade da plataforma e várias questões também sobre aspectos de segurança que eu particularmente nunca usei e acredito que nunca vou usar.

Eu nunca valorizei muito certificações, principalmente Microsoft que até pouco tempo atrás era bem mais fraca, e por isso demorei tanto tempo pra tirar a primeira. Hoje, no nível atual das certificações que já incluem WCF, WWF e WPF acho que começa a ser interessante e valer a pena, pelo menos pela realização pessoal.

Mesmo assim, certificação na minha opinião serve mais como um mecanismo pessoal que diz que o sujeito se interessou e deu-se o trabalho de estudar e fazer as provas do que como um mecanismo de avaliação técnica.

Quem quiser fazer sua prova, pode aproveitar o second shot que ainda está valendo.

Agile Project Management with Scrum: Resenha

2008-09-01T22:22:10+00:00

Assim como o livro do Eric Evans está para modelagem e DDD este livro do Ken Schwaber está para agilidade. É com certeza um “must read”.

Comprei na Livraria Cultura por R$71,00 e tem pouco mais de 150 páginas . O livro é importado então demora um bucadinho pra chegar. No meu caso foram aproximadamente 4 semanas.

O livro não é uma bíblia explicando como utilizar Scrum e nem um guia de implantação da metodologia (até porque os processos e regras são bem simples e existe um outro livro do mesmo autor com esse intuito), mas sim uma parte da experiência que o Ken acumulou a respeito de Scrum desde sua criação e gerenciamento e desenvolvimento de projetos de software.

Apesar de não ser a bíblia, até quem não conhece pode comprar o livro e tirar muito proveito dele, pois o primeiro capítulo e os apêndices são dedicados a descrição do processo e as regras que a metodologia diz que você deve seguir.

O restante dos capítulos é dedicado a histórias curtas (de 2 ou 3 páginas cada) narradas pelo autor e tem como objetivo dar uma mão para aqueles que já implantaram Scrum, mas engasgam no meio do caminho e/ou tem algumas dúvidas a respeito do que pode e não pode.

Como exemplo do conhecimento que o livro oferece, posso citar uma história onde o cliente/patrocinador de um determinado projeto não queria saber de processos e metodologias, mas ainda sim queria poder acompanhar o andamento de seus proejtos. Como tudo o que o cidadão conhecia para acompanhamento de projetos era Gantt Chart, Ken e o Scrum Master do projeto tiveram que bolar outra forma, sem fugir das premissas do Scrum, de reportar o andamento do projeto com sucesso ao gestor ranzinza.

Histórias referentes a todos os papéis do Scrum e suas dificuldades particulares aparecem no livro. Outro ponto interessante que vale a pena citar é que diversas formas de customização e adaptação da metodologia são apresentadas no livro e esse tipo de informação é muito valiosa.

De fácil leitura e entendimento, é um livro obrigatório para os agilistas adeptos de Scrum, escrito por um dos criadores da metodologia e praticante até hoje, que vai ajudar MUITO aqueles que já aplicam Scrum e dar uma prévia dos benefícios oferecidos pelas práticas ágeis aos entusiastas e "scrum-master-wannabe’s" de plantão.

Mudança de endereço do blog

2008-09-01T01:31:11+00:00

Nesta última semana que passou postei pouco por diversos motivos (vocês vão ver daqui a alguns dias). Um deles é a mudança de endereço do blog. Agora com domínio e hospedagem própria (hospedando no eapps.com). Vou manter este aqui por mais alguns dias para que todos possam atualizar seus bookmarks.

O novo endereço é:

http://blog.tucaz.net

(bem grande pra dar destaque!!! ehehhee)

Quem assinava o blog pelo feedburner não deve ter problemas em continuar recebendo as atualizações, mas quem assinava pelo link aqui do wordpress favor atualizar também:

http://blog.tucaz.net/feed

O Host fica localizado nos EUA, portanto é possível que o acesso fique um pouquinho mais lento. Trocar de host vai me permitir muito mais liberdade em futricar no blog e ir melhorando cada vez mais. Ao longo dos próximos dias ainda vou estar mexendo e migrando algumas informações, mas vou tentar não fazer bobagem para que o blog não fique fora do ar.

Se alguém tiver qualquer tipo de problema de acesso (dns, feed, encoding, etc) favor me avisar pra eu corrigir o mais rápido possível.

Download Full .NET Framework SP1

2008-08-25T15:24:18+00:00

Eu gosto bastante do site da Microsoft, mas tenho uma dificuldade pessoal. Sempre que sai um SP de alguma ferramenta da Microsoft eles disponibilizam um setup de ~2Mb e esse é quem baixa todos os arquivos necessários para a instalação da atualização.

No entanto, se você vai instalar a atualização no servidor, não se pode dar ao luxo de conecta-lo na internet para que o download seja feito. Você precisa de uma versão completa do pacote de atualização e é ai que eu me complico pra achar (podem rir...). Dessa vez até que foi rápido, mas pra quem não quiser ter o trabalho de procurar como eu é só clicar aqui e baixar o arquivo completo.

Certificações Microsoft em dobro!

2008-08-23T01:29:35+00:00

Post rápido!

Foi reaberto o programa Second Shot da Microsoft que permite que, caso você falhe na primeira prova, você possa fazer a segunda "de-grátis-na-faixa"!

Clique aqui pra pegar seu voucher.

Daily Meeting e Reunião do AA

2008-08-21T17:04:07+00:00

No nosso último Daily Meeting o Gustavo fez um comentário interessante "Pô! Isso aqui tá parecendo reunião dos alcólicos anônimos!". Depois desse dia eu fui dar uma procurada e de fato o Daily Meeting ou Daily Scrum é bastante parecido com uma reunião do AA.

São diversas as semelhanças no modus operandi, logo os resultados podem no mínimo ser parecidos.

As duas reuniões tem como objetivo a comunicação e utilizar dessa comunicação pra que todos os participantes saiam no ganha-ganha. Quando tornamos hábito o fato de expor nosso dia-a-dia para os outros membros na equipe (assim como no AA) automaticamente o relacionamento entre as pessoas fica melhor e por termos vergonha de falar que fizemos alguma bobagem (beber, por exemplo) nos preocupamos mais com nossas ações e o resultado que elas podem trazer. Outro grande benefício é que podemos compartilhar experiências ruins para que possamos ser ajudados e experiências boas para ajudar outras pessoas.

O melhor de tudo é que o processo todo é bastante simples. Podemos dizer que o custo X benefício é excelente!

Portanto, não deixem de fazer o Daily Meeting!

Estamos contratando!

2008-08-19T13:02:37+00:00

Agora que o blog está ganhando um pouquinho mais de visitas acho que já posso usar dele pra me ajudar a agregar pessoas a equipe. Há pouco tempo atrás eu postei a respeito de como é difícil contratar bem hoje e ainda temos vagas aqui na equipe a serem preenchidas.

Nesse momento, acho que não tem como não roubar um poquinho da descrição das vagas que o Philip anunciava em sua época de Globo.com.

Um dos meu objetivos, desde que assumi posições de liderança, eram prover para a equipe um ambiente bastante descontraido, uso de tecnologia de ponta e todos os outros recursos necessários para que pudessemos trabalhar de forma adequada.

Hoje já estamos muito próximos dessa realidade (ainda temos problemas, é claro!) e a cada dia estamos trabalhando para elevar o conhecimento da equipe, portanto alguns dos requisitos para a vaga são:

Ter vontade de aprender e aceitar estar errado, pois nos desafiamos nossas soluções diariamente então o que era bom ontem pode não ser mais bom hoje e todo mundo em determinado momento vai ter sua solução questionada. Buscar soluções novas o tempo todo a fim de melhorar nosso trabalho e entender quando alguma solução não puder ser aplicada naquele momento.

Deve conhecer razoavelmente bem modelagem (atualmente nós utilizamos DDD) e gostar de desenhar (muito papel também!), pois todo o trabalho de criação é feito sem o uso de ferramentas.

Conhecimento e experiência em processos agéis são um diferencial, mas não obrigatório. No entanto (sei que estou sendo repetitivo) ter mente aberta é muito importante. Aqui a equipe decide como as coisas vão funcionar. Não é o gerente , não é o arquiteto, não é o analista e nem o desenvolvedor. Nós trabalhamos em equipe, portanto auto organização é vital.

Utilizamos Scrum como processo e diversas práticas de XP tais como TDD e Integração Continua. Conhecimentos em infra-estrutura que ajudem a facilitar esses processos são muito bem vindos, pois atualmente temos poquissimas pessoas pra cuidar disso o que acaba sobrecarregando um pouquinho elas.

Como ambiente técnico nós utilizamos somente Microsoft, ou seja, .NET 3.5, SQL 2008/2008, VSTS 2008 e todas suas ferramentas (Database edition, Test edition, etc), Team System como ferramenta de apoio a projeto e muita tecnologia web 2.0 (REST, Ajax, frameworks JS, etc). Trabalhamos também com Spring, frameworks ORM e diversos padrões de projeto.

Dentre todos os aspectos, acredito que conhecimento técnologico tem a menor importância no processo de contratação. Durante o tempo que trabalho com .NET já tivemos 2 caras na equipe que vieram de Java e nunca tiveram nenhum contato com .NET e com certeza eles fazem parte dos melhores que trabalharam comigo. Inclusive, se houver alguém de Java interessado em conhecer a plataforma Microsoft será muito bem vindo! :)

As vagas são pra Pinheiros em São Paulo capital, contratação como Pessoa Jurídica e remuneração relativamente interessante.

De uma forma geral, acho que é isso! Quem tiver interesse favor enviar um curriculum em PDF ou em DOC para azegunis@stefanini.com.br e aguardar contato.

Applying Domain-Driven Design and Patterns with examples C# and .NET: Resenha

2008-08-15T20:22:54+00:00

Terminei essa semana de ler o livro do Jimmy Nilson "Applying Domain-Driven Design and Patterns: with examples in C# and .NET" e vou compartilhar minhas impressões.

É um livro com 11 capítulos, 2 apendíces e aproximadamente 500 páginas. Paguei R$100,00 na Livraria Cultura e chegou em menos da metade das 8 semanas prometidas no site.

Geralmente livros técnicos depois de algumas página se tornam cansativos de ler. Não li nenhum outro livro deste autor anteriormente, mas o cara escreve de uma forma muito gostosa e tranquila de se ler. Nos primeiros dias eu não conseguia fechar o livro. Tive que me segurar pra não passar a madrugada lendo.

Quando comprei o livro imaginei que fosse unicamente a respeito de DDD, mas na prática são poucos os capítulos referentes a esse assunto.

O primeiro capítulo é bastante interessante (principalmente pra quem não está acostumado com agilidade, DDD e Testes) porque ele conceitua esses pontos de uma forma que é impossível não ter vontade de aplicar e ler mais sobre.

A partir dai e durante todo o livro ele apresenta diversos design patterns e como aplicá-los em situações práticas. Existe também um capítulo inteiro sobre TDD que passa por todos os aspectos desde o ciclo de desenvolvimento com TDD, mocks e stubs, e até técnicas de refatoração.

A partir do quarto capítulo que ele comça a falar propriamente dos novos aspectos da modelagem orientada ao domínio e da nova proposta de arquitetura. Sempre com muitos exemplos de código e modelos.

Antes de ler o livro eu havia lido muito a respeito de DDD no GUJ, no resumo do livro do Evans e mais da metade do livro que deu origem ao resumo. Exatamente nesta ordem. Então já estava bem familiarizado com os novos conceitos e já havia aplicado bastante.

Acho que por conta disso, me decepcionei um pouquinho, pois o Jimmy Nilson falou quase nada a respeito de Services e de interações mais complexas entre objetos. Outro ponto que me deixou bastante frustrado foi o fato dos exemplos dos repositórios serem implementados apenas com ORM (NHibernate no caso deste livro). Em Java ORM é uma realidade. Em .NET a coisa ainda está começando a andar com o LINQ, EF.aspx) e o próprio NHibernate, mas a maioria das pessoas ainda implementa acesso a dados na mão. No fundo, acho que o fato de implementar repositório de forma elegante apenas com ORM é um problema do padrão e não do livro (esse é assunto pra um outro post que vai render pedras). Eu particularmente gosto muito de implementar na mão (mais pedras!).

Outro ponto que ficou por último, mas sem menos importância é UI. Ele fala de UI com MVC e MVP inclusive a respeito de como testar a UI. No entanto achei que os exemplos nesse caso não ficaram legais principalmente pelo fato de durante todo o livro o conceito de web ser enfatizado e no caso da UI os testes serem escritos com exemplos em Windows Forms.

Já ao final do livro alguns colegas dele falam a respeito de outros padrões e frameworks tais como: PI utilizando POCO/POJO, SOA, AOP, DI, IoC, NHibernate e SPRING. Inclusive este livro serve como um bom início para o aprendizado desses frameworks, pois os exemplos ilustram cenários bastante reais e práticos.

E por último mais alguns colegas explicam outras abordagens de design de aplicação orientada a domínio.

Se você ficou empolgado por imaginar que fosse encontrar bons exemplos de como testar sua UI nesse livro, acho que essa não é a melhor literatura. Mas para todo o restante dos assuntos é um livro altamente recomendado e que me proporcionou muito aprendizado durante a leitura.

MSBuild com Team System e template de Scrum

2008-08-14T13:59:52+00:00

Hoje estou trabalhando na integração continua do nosso projeto utilizando Team Build do Team System. Quando um Build falha, por padrão um Work Item de Bug é criado pela próprio Team Build. No entanto, se você estiver utilizando um template diferente do padrão (nós utilizamos o template do Scrum) é provável que o Work Item de Bug não seja criado, pois os campos do arquivo padrão do MSBuild que mapeia pro Work Item são diferentes do padrão.

Pra corrigir isso basta abrir o arquivo.proj do seu Build e comentar/apagar/modificar as regiões que ele não estiver conseguindo mapear. No meu caso, o único campo que ele tentava mapear errado era a Reason do Bug que não existe no template do Scrum.

Então no arquivo.proj comentei a seguinte parte:

<WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>

que ficou:

<!-- 
<WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>
-->

Pronto!

Ainda estou engatinhando com o MSBuild. Minhas primeiras impressões são de que ele não é tão difícil quanto parece (principalmente se você gostar de XML, o que não é meu caso) e é bastante completo.

Achei dois links interessantes pra compartilhar:

Blog do Stuart da Conchango (mantenedora do template do Scrum pro Team System) que criou um template de projeto pro visual studio só pra cuidar de builds. Ainda não testei (estou baixando agora), mas parece bem bacana.

E um outro link muito básico, mas que muita gente tem dificuldade de achar que é a documentação oficial do MSBuild.aspx).

Agilidade na confecção de roupas!

2008-08-10T17:30:10+00:00

Ontem a tarde descobri uma coisa interessante: Agilidade é coisa de mulher!

Brincadeira! Mas de fato, em uma conversa ontem com a patroa descobri que as mulheres (pelo menos ela) tem mais facilidade pra entender alguns principios da agilidade do que muitos homens.

Estavamos conversando sobre nossos trabalhos (ela trabalha com logística/compras) e caimos no papo de projetos em geral e no porque especifíco da maioria dos projetos de software falharem. Expliquei pra ela que um dos motivos é a utilização de modelos em cascata onde em um projeto de 12 meses o fornecedor fica 4 meses junto com o cliente no início do projeto e só da as caras novamente 8 meses depois com um software (ou parte dele apenas) fresquinho funcionando.

Foi incrível que no momento que terminei de explicar o processo em cascata e ia começar a falar a respeito de agilidade ela me interrompeu (ela não sabe nada de software) e traçou um paralelo MUITO legítimo que serve como um ótimo exemplo da aplicabilidade de métodos agéis. Explico:

No tempo livre ela pratica dança do ventre e, esse ano junto com seu grupo de dança, ela participou de duas apresentações abertas ao público. Para isso, o grupo teve que encomendar roupas sob medida e combinando até certo ponto entre si. Foi ai que os problemas começaram. Apesar de seguirem um modelo básico -como quando construimos softwares diferentes para o mesmo seguimento de empresas- cada roupa tinha suas peculiaridades -assim como as regras de negócio especifícas de cada empresa-. Ela passou as necessidades de sua roupa pra professora do grupo -podemos chamá-la de analista de negócios- e essa por sua vez especificou para as costureiras da empresa fornecedora -os programadores!- como o cliente queria a roupa. Conversaram uma ou duas vezes na primeira semana e depois de aproximadamente 3 meses a roupa estava pronta e perfeita!

Será que estava mesmo?

É claro que NÃOOOOOOOOOOOOOOOOOOOOOOOOO!

(Até então eu imaginava que processos em cascata falhassem só em projetos de software, mas pelo jeito parece que não)

Já com a roupa nas mãos e p*** da vida por ter gasto uma grana preta com a roupa (acreditem, custa caro) que apesar de seguir um esqueleto básico e padronizado não estava nem perto de estar pronta (tamanho, cores e acessórios errados) ela entrou em contato com o fornecedor. Apesar dos problemas ela imaginou que seria possível consertar a roupa a tempo da apresentação que iria acontecer em 1 mês. No entanto, ao final desse mês e no dia da apresentação a roupa tinha sido consertada, mas ainda estava cheia de problemas -assim como as milhares de não conformidades de software feitos por esse processo-. O jeito foi se apresentar do jeito que estava (meia boca) -ida a produção!- e ainda hoje (6 meses depois) ela ainda esta brigando com as costureiras pra ter a roupa 100%.

O mais interessante é que depois de me contar essa história, ela mesmo conseguiu chegar a solução mais óbvia (que ainda não entra na cabeça da maioria das pessoas no nosso mercado de software) que havia pra evitar ou diminuir os problemas com a roupa: provar semanalmente a roupa junto com as costureiras ao invés de ver apenas o resultado final depois de um tempão. Ou seja, abstraindo um pouco mais temos: ITERATIVIDADE, PARTICIPAÇÂO DO CLIENTE, ACOMPANHAMENTO FREQUENTE e muitos outros príncipios da agilidade.

A idéia dessa analogia que nem saiu da minha cabeça não é mostrar que é possível fazer roupas com metodologias agéis, mas sim o quão prejudicial é desenvolver software sob medida de forma cascateira. Ser ágil, ou ao menos iterativo é muito fácil e os benefícios são claros.

Ultimamente tenho conversado bastante com pessoal da área comercial e todos confirmam o que nós consultores já sabemos: os clientes estão cansados de perder dinheiro com projeto de software! Acredito que agilidade ainda não é uma coisa mais bem aceita e padronizada no Brasil porque a maioria dos clientes compradores de software ainda não sabem que uma alternativa a processos cascata e escopo fechado existe.

Sendo assim, por meio desta analogia das roupas ou por esta outra do Alexandre Magno ou ainda com esta do Vinicius da Improve IT nosso papel é evangelizar os clientes e promover métodos agéis, pois somente desta forma essa bagunça que é nosso mercado hoje vai mudar!

Quando utilizar propriedades ou métodos?

2008-08-04T09:00:01+00:00

A partir do momento que aceitamos ou escolhemos utilizar orientação a objetos acredito que devemos fazer de tudo para utilizá-la da melhor forma, ou seja, criar modelos simples (não simples demais) e que comuniquem seu objetivo de maneira clara e com fácil entendimento.

No entanto, poucas são as pessoas que realmente se preocupam se seu modelo está com o mínimo possível de qualidade (não é?), vista a quantidade de modelos orientados a banco de dados que vemos por ai. Menos pessoas ainda, são as que procuram entender e se aproveitar das sutilezas existentes nos objetos para tornar o modelo mais claro e ter como boa conseqüência a comunicação de suas intenções facilitada.

Bons designers utilizam-se da linguagem pra facilitar seu trabalho.

O ponto que me motivou a escrever sobre isso é o motivador para utilização de propriedades e métodos. Desde a teoria mais básica de orientação a objetos aprendemos que objetos são classes (entidades) que possuem estado (propriedades) e comportamento (métodos) próprio.

Em .NET possuímos propriedades nativamente. Em java obtemos propriedades através de métodos get() e set(), por exemplo. Diretamente ou não, todas as linguagens orientadas a objetos fornecem mecanismos para utilização de propriedades. Mas quando devemos utilizar propriedades ao invés de métodos?

Conforme a própria teoria, propriedades devem refletir o estado de um objeto, ou seja, as características que o definem naquele exato momento de sua vida. Como exemplo simples teríamos dentro de um objeto do tipo Cliente as propriedades: Nome, Telefone, Idade, Sexo, etc. No entanto, a partir do momento em que para responder a uma pergunta sobre seu estado o objeto precise efetuar algum tipo de processamento deveremos transformar a então propriedade em um método, pois propriedades devem ser utilizadas para descrever estado que seja sabido "de bate pronto" pelo objeto em questão. Qualquer outro tipo de resposta a perguntas feitas para o objeto deve ser respondida através de métodos.

Um exemplo um pouco mais concreto: vamos imaginar que estamos desenvolvendo um sistema de controle de usuários e que no momento de uma exclusão de usuário precisamos saber se ele possui ou não emails.

Podemos modelar desta maneira:

Claro que existem exceções, mas normalmente um usuário não sabe se possui emails (a não ser que fique de 5 em 5 minutos apertando o botão send/receive do outlook! :D) e no caso desta pergunta teria que sair de onde está, ir até sua mesa, abrir seu programa de email e verificar se possui ou não algum email. O administrador poderia checar, mas deveria também executar uma série de operações até descobrir se o usuário possui ou não emails. Sendo assim, acredito que essa operação deveria ser comunicada de forma explicita por meio de um método para que quem estivesse utilizando essa API soubesse que uma operação (processamento) irá ocorrer para checar se existem ou não emails.

Outro motivo para utilização de métodos nesses casos é a possível necessidade de passagens de parâmetros para essas verificações. Ainda no nosso cenário de controle de usuários, vamos assumir que um novo requisito deve ser implementado: somente os usuários que não receberam emails na última hora podem ser removidos. Se utilizarmos propriedades como no exemplo acima como iríamos fazer? Criar outra propriedade chamada "RecebeuEmailNaUltimaHora"? Ou poderíamos modelar dessa forma:

Desta maneira, acredito que o mundo real seja mais bem representado e o utilizador da API irá utilizar os métodos com mais cuidado, pois o modelo comunica que para fazer essa verificação é necessário processamento (que pode ou não ser pesado). Outro ponto a favor é que podemos ter (quanto menos melhor) diversos métodos para execução de operações, mas caso esse tipo de checagem deva ser feito de diversas maneiras não podemos sair criando uma propriedade para cada um dos cenários senão corremos um sério risco de desconfigurar a identidade do objeto por ter propriedades demais.

Como tudo em OO, não devemos ter isso como uma regra, mas sim verificar o que é melhor para cada cenário. Acredito que mais do que a sugestão apresentada nesse post, o mais importante é a mensagem de que devemos modelar com cuidado procurando abstrair nosso domínio da maneira mais fiel possível e comunicando o máximo através das ferramentas que a OO nos oferece.

Dica de Blog!

2008-07-31T11:07:36+00:00

Ontem a noite eu estava navegando atrás de mais informações a respeito de Team Build e encontrei um blog com várias coisas úteis, inclusive add-ons para o próprio Team System. O blog já não é mais atualizado ha pelo menos um ano, mas os archives são realmente bons.

O endereço é: http://blogs.vertigosoftware.com/teamsystem/

As pessoas merecem o trabalho que tem

2008-07-31T00:02:07+00:00

Existem algumas coisas que são engraçadas... com qualquer linguagem que se trabalhe, desde as mais novas até as mais antigas, vejo gente reclamando do trabalho que tem. Seja pela empresa que não deixa o cara crescer, seja pela tecnologia que utiliza e não pode mudar ou seja pelo processo que é muito engessado. Só reclamações.

No entanto nada fazem para mudar isso.

No meu atual projeto estamos pagando relativamente bem (se comparado com a maioria das consultorias de body shop), temos um ambiente bastante descontraido, estamos implantando metodologias agéis no lugar do processo cascata, trabalhamos com tecnologia Microsoft de ponta (.NET 3.5, SQL 2005/2008, SSIS), temos o apoio de ótimas ferramentas e ainda assim não conseguimos preencher as três vagas que temos abertas. Por que? Por que exigimos muitos conhecimentos nas tecnologias citadas? Não! Mas porque as pessoas não querem mudar.

Hoje por exemplo, tinhamos duas entrevistas marcadas. Nenhum dos candidatos apareceu ou sequer ligou para avisar que não iria poder comparecer ou que não tinha mais interesse na vaga. Se formos pensar um pouco no assunto não é muito dificíl entender a razão disso acontecer. De acordo com as pesquisas que o Luciano citou nesse post existem mais vagas do que profissionais disponíveis, muito mais! Sendo assim, poucas são as pessoas que dão a atenção devida para um compromisso tão importante como uma entrevista. E mais importante ainda quando a questão $financeira$ e técnica são favoravéis.

Não é a primeira vez que isso acontece. Nos últimos dois anos sempre esbarramos nessa dificuldade em contratar. Pessoalmente, acho que é uma pena para ambos os lados: a) para o contratante que se vê refém da falta de profissionais ou da esbórnia que é o mercado e é obrigado a contratar sem critérios, contribuindo para que isso continue acontecendo e b) para os profissionais da área que deixam de investir nas formação profissional e pessoal e agem da maneira que descrevi acima. É importante perceber, que nesse momento nem os profissionais e nem as empresas contribuem para mudança desse cenário.

O ponto positivo é que esse cenário está cada vez mais evidente a todos e é um cenário longe do adequado. Logo, seguindo a lei de Darwin (ele mesmo que falou das girafas?), esse modelo deve cair. A partir dai ou as empresas vão diminuir seus projetos de TI por não conseguirem os profissionais necessários ou então os profissionais vão evoluir de acordo com a necessidade das empresas fazendo com que o equilibrio seja alcançado. De um jeito ou de outro, acredito que estamos caminhando para frente. Só espero que não demore tempos demais até chegarmos lá.

Claro que essa é apenas uma das minhas teorias com relação a esse assunto dentre as outras que tenho e milhares que podem ser encontradas navegando um pouco na internet.

Scrum Planning!

2008-07-25T01:12:00+00:00

Hoje no fim da tarde tivemos nossa primeira reunião de planning. O objetivo era traçar a estratégia para implementar as últimas funcionalidades de um dos módulos do projeto que estamos desenvolvendo. Como o product backlog esta bem pequeno nesse momento serão somente necessários 2 sprints (definimos duas semanas de prazo) pra terminá-lo. Ainda assim acho que a reunião foi bastante produtiva.

Os pontos positivos foram:

De uma forma geral todo mundo participou, ou opinando nas funcionalidades ajudando a agregar mais valor ao cliente ou na estimativa do prazo (utilizamos horas ao invés de pontos, pois precisavamos dar um prazo mais confiável pro cliente)
Dada a participação das pessoas, existiram ganhos reais nas histórias inicialmente levantadas pelo PO
A equipe realmente pareceu uma equipe. Existiu um pouco de stress, mas acho que nada acima do que seria normal!
Acredito que o PO ficou bastante confiante com as estimativas e com a qualidade que ele vai receber ao final do sprint
Conseguimos cumprir os objetivos da reunião nas 4 horas limite :D

Com relação a pontos negativos, tenho mais do que positivos pra listar, mas de menor valor. São eles:

O espaço pra nossa reunião realmente é muito pequeno então alguns membros do time ficaram relativamente desconfortáveis
Nosso time tem 12 pessoas, ou seja, 4 acima do recomendado pelo SCRUM. Ao final da reunião quebramos em dois times (um deles já vai iniciar outro módulo), mas todos participaram da reunião o que gerou bagunça ao longo da reunião
Não tinhamos o product backlog inteiramente concluido e nem priorizado então tivemos que parar no meio para inserir as histórias na ferramenta (excel + Team System) para que o PO pudesse priorizar
Estamos apanhando um pouco da ferramenta. Como não temos espaço pra quadro branco a solução é cadastrar e gerenciar os backlogs e atividades dos sprints através da ferramenta que acaba tirando um pouco do dinamismo do SCRUM.
Como utilizamos quase 4 horas pra fazer tudo que era necessário, não temos lugar muito adequado e não estamos habituados com reuniões dessa duração (principalmente o PO) as vezes o pessoal dispersava a atenção ou entrava em brincadeira, mas conseguimos contornar numa boa
Por causa do velho hábito ainda fizemos algumas estimativas pensando em quem iria fazer cada atividades quando o ideal seria estimar sem esse direcionamento

Apesar dos problemas, todos sairam da reunião muito empolgados e com vontade de terminar o sprint logo, pra ver o que vem pela frente.

Amanhã tem planning do outro módulo com o time 2.Vamos ver o que acontece :)

Adoção de Scrum

2008-07-23T21:36:00+00:00

Estamos no atual projeto desde fevereiro, trabalhando em modelo cascata dos brabos. Como era de se esperar tivemos todas as terríveis experiências que esse modelo pode proporcionar:

Inexistência da participação do cliente
Atraso nas entregas
Entregas que não atendem o objetivo do cliente
Foco em documentação que fica desatualizada, ou seja, inútil
Não cumprimento dos objetivos de ROI
Bugs
Retrabalho

Enfim... fins de semanas perdidos...

Ta certo que quando iniciamos o projeto nós e o cliente já tinhamos o sentimento de que não iamos concluir tudo no prazo estipulado, mas havia a esperança otimista (falsa, no caso do modelo cascata) de que podiamos superar as expectativas.

Fazem uns 3 meses que eu venho lendo bastante a respeito de agilidade no GUJ e blogs do pessoal de lá e chegou a hora de mudar.

No último sábado participei do Workshop de SCRUM com o Rodrigo. Pouca coisa quanto a teoria (que eu já havia estudado exaustivamente) foi acrescentado, mas MUITO foi agregado nas experiências e na forma de tocar um projeto com SCRUM.

Muito bem. Essa semana eu e o André (GP do projeto) fizemos um workshop de dois dias com toda a equipe e o cliente a fim de mudar radicalmente nossa forma de trabalho. Desde o processo (vamos utilizar SCRUM junto com Team System) até modelagem saindo de um modelo anêmico e com processo de qualidade artesanal para algo próximo de DDD com TDD. Uma revolução para equipe e para o cliente!

O resultado dos dois dias foi: 90% da equipe super entusiasmada com todas as idéias e com o horizonte de ter uma boa parte das funcionalidades entregues dentro de um prazo aceitável. O cliente gostou bastante do processo também, mas ainda tem a falsa percepção de que um projeto sem um calhamaço de documentos não é legal. Conversamos bastante e nesse ponto fizemos um acordo em busca do meio termo. Vamos fazer a documentação que o cliente achar que devemos fazer. Não vamos estipular uma regra-de-prata, mas sim definir durante os sprints o que será mantido como documentação ativa no projeto.

Uma das coisas que particularmente me atrai no SCRUM é o fato do cliente priorizar o que vai ser feito então se ele quiser MUITA documentação vai acabar recebendo poucas histórias implementadas.

Acredito que conforme os sprints forem correndo e o cliente pegar mais segurança com relação a qualidade do trabalho essa noção de documentação melhore e nossa vida venha a ficar mais fácil nesse aspecto.

Conforme conselho do Rodrigo para iniciar com o uso de SCRUM, marcamos nossa primeira reunião de planning e vamos começar a utilizar o processo. Tenho bastante esperança de que o sucesso vai vir, mas tenho consciência de que não virá de uma hora pra outra.

Nesse momento principais pontos que temos a vencer são os débitos ténicos. O projeto depende de algumas integrações que estão meio capengas e os builds são bastante complicados por enquanto. Outro ponto é que o SCRUM é fortemente baseado em modelagem e reuniões com o uso de papel e lousa. O problema é que não temos espaço disponível pra fazer o "deploy" desses objetos (a lousa principalmente) e nem reuniões com a equipe inteira então vamos ter que nos virar com as abstrações dos post-its que o Team System consegue nos fornecer e um espaço meio apertado pra equipe toda. A última fatia que temos que adaptar é o fato de termos diversos casos de uso e a resistência do cliente em transformá-los em histórias. Sendo assim, vamos ter que improvisar a manter a referência das histórias aos casos de uso.

Acho que após superarmos esses aspectos tudo deve decolar! Mesmo que não decole como um foguetão turbinado, só o fato de melhorarmos a modelagem, introduzirmos testes e trabalhar iterativamente já vai nos trazer ganhos.

Conforme formos avançando (ou não) vou postando a respeito da experiência.

O papel do Arquiteto...

2008-05-22T02:48:00+00:00

De uns tempos pra cá venho percebendo que o papel do "Arquiteto de Software" tá na boca do povo e em muitos lugares as pessoas falam, falam e falam a respeito do que esse fulano deveria fazer e/ou não fazer. Hoje recebi o último Architecture Journal que fala apenas a respeito deste papel dentro das empresas e do processo de desenvolvimento e manutenção de sistemas e como estou cada vez mais assumindo esse título decidi tentar colocar resumidamente o que eu penso a respeito desta importante figura.

Na realidade, eu não gosto muito do título, pois por toda minha vida profissional (que não é tããããão longa assim) eu acreditei que esse cara era o guru da sapiência e que ele nunca ficaria sem respostas a qualquer pergunta que fosse feita. Então, soa como uma responsabilidade muitooooo grande (e é mesmo) pra um desenvolvedor de apenas 21 anos como eu. De fato, deveria ser assim, mas é humanamente impossível ser ao mesmo tempo generalista e especialista em todas as áreas. Isso me frustrou um pouco, mas ao mesmo tempo, por outro lado abriu minha cabeça e me fez reconhecer que existem diversos tipos de arquitetos, cada um na sua. E que existem pessoas, mesmo sem carregar o título, que também fazem arquitetura em um momento ou outro de um projeto. É baseado em conhecimento próprio e utilizando o conhecimento dos membros da equipe que o arquiteto deve trabalhar.

Inicialmente, dentro da área de software (imaginando que infra-estrutura não exista) eu identifico dois principais arquitetos: Arquiteto de Soluções ou Corporativo e Arquiteto de Sistemas. O primeiro deles define quais tecnologias, metodologias e ambientes serão utilizados para os sistemas da empresa e procura manter todos os sistemas seguindo essas linhas agindo de forma incisiva nas fronteiras entre implementação e processos de negócio sem dar muita atenção nos detalhes técnicos de cada sistema.

Já o segundo, que é onde eu me encaixo por trabalhar em consultoria atendendo a diversos clientes, é o cara que dado um projeto deve atuar em todas as etapas da construção do sistema. Desde levantamentos inicias, passando por implementação e até roll-out em produção. Além das habilidades técnicas que são imprescendiveis nesse papel e isso ninguém pode negar, o arquiteto deve ser um cara balanceado pra atuar como um mediador entre todos os stakeholders do projeto. Em um projeto com papéis bem definidos, a tendência é que cada um cuide das apenas das suas responsabilidades. Isso é bom, pois cada especialista atua onde mais conhece, mas se não houver cuidado, pode fazer com que os principios inicialmente definidos não sejam seguidos. É ai onde o arquiteto deve entrar pra fazer com que todas as diretivas sejam seguidas. Isso exige liderança, habilidades em negociação e muitas vezes pulso forte pra suportar caras feias que aparecem quando uma decisão não agrada a todos.

No âmbito técnico, além de definir um modelo a ser seguido para implementação, ele deve atuar junto a equipe de análise nas etapas de modelagem a fim de entender do negócio para que seja possível escolher as tecnologias que melhor se encaixam no domínio de negócio. Uma vez modelado o domínio de negócio e tendo as tecnologias definidas, ele deve atuar junto a equipe de desenvolvimento guiando a implementação e removendo possíveis roadblocks. Sempre que houver um conflito técnico, ele deve atuar em prol do projeto para decidir a questão independente de chateação ou não por parte dos membros da equipe.

E pra finalizar, deve conhecer metodologia e processos de desenvolvimento a fim de tornar o planejamento e execução dos projetos mais baratos e acertivos.

Dava pra ficar enumerando a respeito das skills e habilidades que um arquiteto deve ter, mas em resumo acho que isso é o principal. O importante é ter em mente que não importa o quanto estudemos nunca vamos chegar no que eu imaginava que existia: arquitetos-sabe-tudo.

Ao longo dos dias vou procurar postar entries nessa categoria pra ir complementando os pensamentos e ai, quem sabe um dia, eu formato tudo num grande apinhado de informações! ehehehe...

Soçarba

E quem disse que o WCF não tem limite?

2008-05-17T02:33:00+00:00

Apesar de ter estudado bastante, feito alguns POCs e lido Inside Windows Communication Foundation inteiro (é, nem eu acredito), desde que comecei a trabalhar com WCF em aplicaçoes grandes de verdade, que nao tinham como objetivo servir apenas um departamento de 50 usuários, estou me sentindo meio barriga verde...

Hoje foi mais um dos momentos (em uma outra oportunidade eu coloco os outros) em que a coisa quase deu m****! Por uma série de motivos decidimos constuir em um ínico serviço WCF todas as funcionalidades de um determinado módulo do sistema. Sendo assim, o serviço está hoje com 63 método e crescendo... No entanto, qual foi a surpresa quando decidi atualizar a referência para o serviço após muda-lo novamente?

"The maximum nametable character count quota (16384) has been exceeded while reading XML data. The nametable is a data structure used to store strings encountered during XML processing ÎÎ long XML documents with non-repeating element names, attribute names and attribute values may trigger this quota. This quota may be increased by changing the MaxNameTableCharCount property on the XmlDictionaryReaderQuotas object used when creating the XML reader"

Ou seja, ferrou! A equipe de desenvolvimento ficou quase 2 horas "semi-parada" esperando a resoluçao do problema. Depois de pesquisar bastante ainda nao tinha achado uma soluçÎÎo que fosse satisfatória para o problema. Na prática, o problema acontece pois o XMLDictionary, por padrao, nao consegue armazenar mais do que o valor default de chaves/valor referentes ao XML gerado pelo MEX/WSDL do WCF. Algumas das soluçoes apresentadas envolviam gerar o proxy do WCF diretamente através do svcutil.exe ou até mesmo em runtime! Para atualizaçoes feitas de tempos em tempos até acredito que a utilizaçao do svcutil.exe diretamente nao é problema, mas no meio do desenvolvimento é um parto! No final, juntando alguns posts em blogs e msdn consegui chegar a soluçao que me servia: Criar um arquivo de configuraçao para o svcutil.exe com um bindind customizado aumentando esse limite. Existem duas formas de fazer:

Criar um arquivo svcutil.exe.config no diretório padrÎÎo onde o svcutil.exe está (geralmente dentro de \Program Files\Microsoft Visual Studio 9.0) contendo as configuraçoes abaixo. No entanto nao sei porque (e nem vou saber, porque no momento a opçao 2 resolve pra mim) meu svcutil.exe se encontra no diretório do framework e se eu colocar o arquivo.config lÎÎÎ quando o VS2008 chamar o svcutil.exe por trás dos panos o arquivo.config nÎÎo ÎÎÎ carregado.

Modificar o machine.config (geralmente dentro de \WINDOWS\Microsoft.NET\Framework\v2.0.50727) adicionando as chaves abaixo. Caso a chave já exista, adicione o dentro da existente.

 <system.serviceModel>
 <bindings>  
     <custombinding>  
         <binding name="CustomSizeMex">   
             <textmessageencoding>   
                 <readerquotas maxdepth="2147483647" maxstringcontentlength="2147483647" maxarraylength="2147483647" maxbytesperread="2147483647" maxnametablecharcount="2147483647">   
             </readerquotas></textmessageencoding> <httptransport maxreceivedmessagesize="2147483647" maxbuffersize="2147483647">   
         </httptransport></binding>   
     </custombinding>   
 </bindings>   
 <client>   
     <endpoint binding="customBinding" bindingconfiguration="CustomSizeMex" contract="IMetadataExchange" name="http"></endpoint>
 </client>   
 </system.serviceModel>

E é isso! Reiniciar o VS2008 e mandar atualizar a referência ao serviço monstro! Tudo funcionando bonitinho

Espero que daqui pra frente os sustos diminuam! :)

O profissional barriga verde...

2008-05-16T02:29:00+00:00

Do meu humilde ponto de vista existem três perfis básicos distintos de profissionais de TI: a) aqueles que adoram o que fazem e por conta de experiência e muito esforço aplicado conseguem de alguma maneira se manter antenados na maioria das coisas interessantes e úteis que aparecem e aplicá-las, b) o extremo oposto disso que são profissionais que estão na área de TI e tomam isso apenas como uma forma de ganhar dinheiro suficiente pra levar a vida e c) os caras que nós últimos dias eu consegui (com a ajuda do meu amigo Tuxo) qualificar como barrigas verdes.

E é sobre esse último perfil que eu quero falar. Me desculpem os catarinenses pelas próximas frases mas ai vai...

Barriga verde é o cara que pode no futuro virar tanto o perfil a) quanto o perfil b) dependendo do que ele conseguir aproveitar das experiências as quais ele teve oportunidade de se submeter. Explico. Quem nunca viu um cara que não é bom e nem é ruim, não apresenta domínio pleno das coisas com as quais trabalha, mas no final consegue terminar um projeto com aceitável sucesso? Eu cruzo o tempo todo com caras desse tipo e inclusive estou me sentindo um pouco assim atualmente. Desde que assumi o papel de desenhar e ajudar a implementar a arquitetura dos projetos que participo, de vez em quando bate um frio na barriga. Esses caras por sorte, milagre, reza ou sei-lá-o-quê conseguem fazer tudo dar certo no final, mas quem acompanha eles de perto percebe que ao menor deslize tudo pode vir a explodir!

Espero (no fundo eu acredito bastante nisso) que com o passar do tempo essa insegurança e medo de por tudo a perder por querer experimentar uma coisa nova me levem ao perfil a). Mas isso... só o tempo poderá mostrar...

Soçarbas!