Com as chuvas e todos problemas que rolaram aqui em Blumenau e região nas últimas semanas, acabei me afastando um pouco do blog, mas agora estou retomando as atividades com um postsobre o Design Pattern Repository. Já utilizo esse design pattern desde o ano passado, mas o que mais me motivou a escrever o post foi ter visto que o novo enginede CMS/Blog que a Microsoft liberou também utiliza este design pattern.

Também tenho dispendido muito tempo em estudar algumas coisas novas (ao menos para mim): Jquery, ASP.NET MVC e minha paixão do momento: dados espaciais. Assunto para o blog não vai faltar :)

Para deixar o blog mais dinâmico implantei aqui do lado um widget com um Twitter. Aos poucos estou me habituando a utilizar essa ferramenta.

"Subindo" um pouco o nível da série de posts sobre design patterns, falarei hoje sobre o pattern "Repository".

Este pattern não é tão amplamente difundido, apesar de sua grande flexibilidade e poder de resolver nosso velho dilema de como isolar a persistência das demais camadas permitindo uma arquitetura plugável onde podemos utilizar múltiplos bancos de dados (na verdade, uma implementação concreta de repositório pode persistir dados em qualquer lugar, não necessariamente direto em um banco de dados.

Um repositório media o relacionamento entre o dominio e os dados. Imagine um repositório literalmente: é um lugar onde são guardadas coisas e coleções de coisas e onde efetuamos pesquisas dessas coisas.

Fonte: http://www.martinfowler.com/eaaCatalog/repository.html

Leia mais...

Nessas últimas semanas vários blogs (inclusive ScottGu)comentaram sobre o intellisense do JQuery no Visual Studio 2008.  Para quem está usando esse framework com aplicações .Net, o uso do intellisense ajuda muito e vale o pequeno esforço para instalar o hotfix do VS 2008.

No entanto, para quem está usando o ASP.NET MVC alguns problemas persistem.
Normalmente fazemos referência ao JQuery na MasterPage e por padrão o link fica dessa forma:

<script src="../../Scripts/jquery.js" type="text/javascript"></script>

A Masterpage de aplicações MVC esta em (root)/Views/Shared. Se temos uma view que está respondendo no mesmo nível (por exemplo, (root)Views/Home/Index.aspx), a chamada acima funciona normalmente. No entanto, se temos views em outros niveis ou se nosso site está em subdiretório (como por exemplo, este blog que está em http://www.bizness.com.br/weblog) começamos a ter problemas.
Para resolver isso, podemos usar um método do framework MVC para renderizar o caminho relativo em runtime:

<script src="<%=Url.Content("~/Scripts/jquery.js")%>" type="text/javascript"></script>

Agora criamos outro problema: o intellisense não reconhece essa forma de chamar o script. 
Para contornar, podemos usar uma chamada falsa ao javscript:

<script src="<%=Url.Content("~/Scripts/jquery.js")%>" type="text/javascript"></script>

    <%if (false)
      { %>
            <script src="../../Scripts/jquery.js" type="text/javascript"></script>
    <%} %>

Tabajara code detected!! Sim, um tanto freak, mas resolve. Como estamos isolando a segunda chamada por um if que sempre retorna falso ela nunca será renderizada na página final, mas em modo design será reconhecida pelo intellisense.

Adaptei a dica que Jeff King deu para que usercontrols .ascx tenham intellisense do Jquery quando a chamada para ele está na masterpage. (os aspx tratam as chamadas que estão na masterpage, mas os ascx não, pois eles não estão ligados a uma página ou masterpage específicos.

A Microsoft jura que não mas ao que tudo indica, para aplicações WEB será adotado o padrão MVC, através do ASP.NET MVC, ficando os Web Forms em segundo plano.

Apesar de ser uma grande quebra de paradigma em relação aos “antigos” Web Forms, a introdução deste padrão traz consigo uma série de vantagens, entre as quais eu destaco a maior facilidade de deixar o site dentro dos webstandards, a testabilidade e uma série de recursos que deixam o trabalho mais produtivo.

Dificilmente alguém irá converter todo um projeto web já pronto em Web Forms de uma só vez para MVC, afinal isso exigiria tempo e dinheiro que ninguém tem.
Felizmente, é possível conviver com os dois tipos de padrões ao mesmo tempo, possibilitando uma conversão gradual e/ou usar o que cada  padrão tem de melhor.

Por outro lado você pode preferir (como eu), usar o tipo de projeto “Website” ao invés do tipo Web Application que vem por default no ASP.Net MVC. As dicas abaixo servirão para esse caso também.

Instalando o Kit-Gás no seu Web Site.

É extremamente simples deixar seu site preparado para trabalhar de forma híbrida:

Leia mais...

Em aplicações asp.net (webforms), uma das dúvidas freqüentes é o que fazer após uma ação, como por exemplo, gravar um novo registro. Acredito que seja comum a simples exibição de uma mensagem “Registro salvo com sucesso”, na mesma página onde os registros foram salvos.
Alguns problemas podem ocorrer com essa prática: caso o usuário submeta o formulário novamente, o registro poderá ser duplicado. Se pressionar atualizar, será exibida uma mensagem como a abaixo (a mensagem pode variar de acordo com o browser):

Para evitar esse tipo de problema deve-se procurar utilizar o Design Pattern PRG, onde após um post (submit), respondemos com um redirect para uma nova página, ao invés de simplesmente retornar um HTML, ou seja, no caso do asp.net, utilizamos o comando Response.Redirect(“pagina_sucesso.aspx”) para direcionar à uma nova página onde informaremos que o registro foi salvo com sucesso.

Faz tempo que não falo da Google. Aliás, faz certo tempo que não falo de nada aqui, e vou quebrar o jejum com uma notícia muito interessante: os serviços Google para clientes da versão “premier edition” agora contam com SLA (Service Level Agreement) de 99.9% para os serviços. Google Calendar, Google Docs, Google Sites, and Google Talk. Esse SLA já estava disponível para o Gmail

Isso é uma boa notícia, principalmente para as corporações que precisam de serviços básicos como agenda, planilha e documentos em cloud e/ou não querem investir em infra interna.

Segundo o Blog do Google, no último ano o Gmail conseguiu 99.9% de disponibilidade. Pense no seu provedor de email (seja ele o Terra, UOL, algum fundo de quintal qualquer ou o mesmo provedor que hospeda suas páginas). Será que você conseguiu tanto tempo de disponibilidade assim em um desses fornecedores?
Quantas vezes você já ficou sem acessar seu email? Quantas vezes você já perdeu seus emails ao trocar de provedor, formatar sua máquina, etc, etc.

Uso o Gmail desde 26/07/2004 (data da primeira mensagem que tenho arquivada). Tenho milhares de mensagens arquivadas (só apago as realmente inúteis). Acesso meu email de qualquer lugar a qualquer hora, com qualquer dispositivo. Nunca passei raiva, nunca precisei xingar.

Recentemente passei a manter todos os meus docs on-line no Google Docs. Além disso, mantenho uma base de conhecimentos em fotografia (meu assunto offline preferido!) usando o Google Sites (que é uma espécie de wiki no final das contas).

Apesar de meu ganha-pão ser no mundo Microsoft, sou obrigado a reconhecer que nesses serviços (e em outros como o Google Maps) a Google está muito na frente da Microsoft. O Hotmail (ou Windows Live Mail, como preferirem) é inusável se comparado com o Gmail (é lento, cheio de propaganda, etc). E, sinceramente, ainda não confio o suficiente nesses serviços da Microsoft ( lá se foi qualquer chance que eu tinha de ganhar algum título MVP! ).

Quem trabalha no desenvolvimento de aplicações asp.net deve ter se deparado várias vezes com a necessidade de depurar código diretamente no servidor de produção (ou de testes). Situações como implementação de operações de cartões de crédito em B2C são difíceis de se reproduzir na máquina de desenvolvimento pois envolvem callback externo.

Se você tem acesso ao seu servidor, pode utilizar o recurso de debug remoto do Visual Studio. É algo relativamente trivial de ser feito, mas pouco comentado.

Leia mais...

Continuando a série Design Patterns, nessa parte 2 iremos ver o padrão Observer.

Suponha que você tenha uma linha de produção que é automaticamente alimentada de componentes por diversos robôs assim que entra um novo pedido. Cada robô solta um determinado número de peças por quantidade de pedido.

Uma primeira abordagem seria algo como abaixo:

using System;

namespace NadaObserver
{
    class Program
    {
        static void Main(string[] args)
        {
            LinhaProducao linha1 = new LinhaProducao();
            Robo wallE = new Robo("Wall-E",linha1, 1);
            Robo c3po = new Robo("C3PO", linha1, 10);
            Robo sonny = new Robo("Sonny", linha1, 20);
            Robo terminator = new Robo("Terminator 800", linha1, 1000);

            //entrou novo pedido de 10 peças
            Pedido ped = new Pedido(10);
            
            // põe o povo para trabalhar

            wallE.SuprirPecas(ped.QtPedido);
            c3po.SuprirPecas(ped.QtPedido);
            sonny.SuprirPecas(ped.QtPedido);

            Console.ReadLine();
            
        }
    }

    public class Pedido{

        public Pedido(int qtPedido)
        {
            this.QtPedido = qtPedido;
        }

        public int QtPedido { get; set; }
       
    }


    public class LinhaProducao{

        public LinhaProducao()
        {
        }

        public void ReceberPecasDoRobo(int qtPecas)
        {
            Console.WriteLine("Recebi {0} peças para montagem", qtPecas);
        }
    }

    public class Robo
    {
        private int _fatorPecasPorPedido = 1;
        
        private LinhaProducao _linhaDeProducao = null;

        public Robo(string nomeRobo, LinhaProducao linhaDeProducao, int fatorPecasPorPedido)
        {
            this.NomeRobo = nomeRobo;
            this._linhaDeProducao = linhaDeProducao;
            this._fatorPecasPorPedido = fatorPecasPorPedido;
        }

        public string NomeRobo { get; set; }

        public void SuprirPecas(int qtItensPedido)
        {
            this._linhaDeProducao.ReceberPecasDoRobo(qtItensPedido * this._fatorPecasPorPedido);
        }
 
    }
}

Além de deselegante, essa solução trás alguns problemas: a aplicação chamadora sempre deverá saber quais são os robôs que estão ligados à cada linha de produção.

Leia mais...

Talvez uma das coisas que mais perturbam os usuários da web seja a necessidade de decorar vários logins e senhas para os diversos sites onde eles possuam uma conta.

Para solucionar isso existem várias iniciativas de se criar “passaportes universais”, como por exemplo, o OpenId.

A Microsoft disponibiliza também uma solução para isso, o Windows Live ID Web Authentication com o qual os usuários podem se logar nos sites usando a mesma conta do Hotmail/MSN. Para os desenvolvedores é uma solução interessante pois traz agilidade na autenticação para milhões de pessoas que já possuem uma conta no MSN.

O WLIWA (abreviando) é um serviço altamente escalável pois fornece, segundo a Microsoft, mais de 22 bilhões de autenticações/mês (cada vez que uma pessoa entra no MSN ela está se autenticando pelo WLIWA). A segurança dele é auditada constantemente o que nos dá uma segurança a mais. Considerando as preocupações que temos com segurança, deixar a autenticação com um especialista já nos poupa muito trabalho.

Veja no diagrama abaixo  como funciona  o processo de autenticação:

Perceba pelos ítens 3 a 7 que o usuário passa seus dados de autenticação DIRETO para o Windows Live Id. Seu site não toma conhecimento dos dados de login do usuário (o que é uma segurança para o seu usuário).
Assim que a autenticação for concluída com sucesso, o WLIWA retorna para o seu site um token com o identificador único do usuário. Esse token você irá usar para autenticar o usuário em sua aplicação.

Li hoje esse post e achei interessante compartilhar. Jason Young sugere algumas questões que você deveria fazer durante uma entrevista de emprego para seu possível empregador.

Longe de ser petulância, essas perguntas evitam futuros dissabores para ambas as partes. Já fui empregador também e sei que nada disso é absurdo ou ofende o entrevistado.

Vou traduzir algumas de forma “livre”, até porque algumas necessitam de “regionalização”:

1) Que tipo de controle de versão vocês usam?

No Brasil, infelizmente, primeiro temos que perguntar se a empresa faz controle de versão, já que não é uma cultura muito difundida principalmente nas empresas mais antigas.

Se a empresa ainda usa Source Safe, fique preocupado! Empresas mais atualizadas procuram utilizar controles mais modernos como o Subversion ou o Team Foundation Server.

Leia mais...