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:

1. Efetuar o download do código fonte, compilá-lo e efetuar a instalação
2. Baixar um pacote cross-platform que faz a instalação de tudo
3. 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

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!

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:

1. Carregar todos os registros da tabela em um List<>
2. 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

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!

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!

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!

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

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!

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

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.

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!