Pessoal,
estou escrevendo uma série de posts sobre MongoDB, no meu novo blog em http://anobre.net/.
Leia, participe, visite!
Abraços!
Estamos trabalhando em um projeto, aqui na NBR, para criar uma plataforma de comércio eletrônico. Um dos pré-requisitos essenciais é a performance de toda a aplicação, mas principalmente das vitrines e detalhes de produtos, que normalmente contam com uma exigência maior de performance dado o alto número de visitantes.
Por outras experiências sabemos que o catálogo, com toda sua complexidade de descontos, promoções, campanhas e outros fatores, torna qualquer consulta algo crítico quando inserido em um cenário de stress. Sabendo disto, tentamos criar neste projeto algo baseado em uma estrutura de dados que favorecesse a estrutura real das características do catálogo, já formatado de uma maneira mais direta para o nosso e-commerce.
Para isto, realizamos algumas pesquisas e benchmarking sobre algum produto baseado em NoSQL, pois é exatamente esta abordagem que precisamos.
Como chegamos à conclusão de utilizar NoSQL?
No início de todo projeto aqui na empresa, que exige certa preocupação com volume de acesso e/ou uma estrutura que diferente do modelo tradicional relacional, temos uma tarefa de definição da estratégia de persistência de dados. Assumimos que não são todos os casos que base de dados relacional é o ideal. Para isto, discutimos abertamente entre a equipe qual seria o adequado para os pontos em que inicialmente identificamos algo "diferente".
Neste projeto, em todas as telas de navegação teremos inúmeros filtros que estarão disponíveis 100% do tempo, e seus resultados serão apresentados através de ajax. Isto nos levantou um ponto importante: por não ter post-back e pela combinação de filtros não ter limitação, enfrentaremos muito mais consultas do que o usual. E consultas com filtros aplicados é igual a busca, e busca exige atenção. Além disto, as páginas de detalhe de produto são muito acessadas.
Então por que não disponibilizar o catálogo de produtos de uma forma melhor estruturada do que aquelas inúmeras tabelas convencionais, além de fornecer uma performance melhor de consulta? Esta foi a pergunta que fizemos, e estas abaixo são as respostas.
Qual produto a utilizar?
Baseado neste análise inicial, começamos o processo de pesquisa para qual produto utilizar. Decidimos pelo MongoDB, por unir as seguintes características:
- Schema Free;
- Possibilidade de replicar os dados em servidores "slaves";
- Baseado no modelo key-value;
- Alta performance nos nossos PoCs realizados;
- Facilidade de desenvolvimento e deploy (maturidade da ferramenta);
- Cases apresentados;
Como foram realizados os primeiros testes?
Os primeiros testes realizados para comprovar nossa escolha foram os mais básicos possíveis. Através de um catálogo muito similar, criamos as bases de dados e as consultas mais simples via Entity Framework Code First. Pegamos o mesmo catálogo, criamos a estrutura e inserimos os dados no MongoDB, em uma base específica para este teste.
A nossa idéia era executar um conjunto de buscas e analisar o tempo de resposta de cada um deles. Em resumo, nos cenários abaixo (que é onde utilizaremos), o MongoDB foi inúmeras vezes mais rápido do que o SQL Server:
- Iniciar Conexão, realizar consulta simples e fechar a conexão
- Iniciar conexão, realizar consulta baseada em campo indexado e fechar a conexão
Observações Importantes:
Alguns de vocês devem estar se perguntando: vocês não vão incluir cache na aplicação? E Akamai?
Normalmente no nosso dia-a-dia incluímos o cache na aplicação, e neste caso não será diferente. Os resultados das consultas no MongoDB serão cacheadas, o que nos trará ainda mais performance. Sobre Akamai, no nosso desenvolvimento não consideramos que temos esta ferramenta, pois nunca se sabe quando o cliente optará por outra ou nenhuma ferramenta neste sentido.
E o que mais será utilizado na persistência do catálogo?
Independente desta solução baseada no MongoDB, não iremos descartar o SQL Server. O fluxo é o seguinte: as informações de catálogo chegarão por integração até a base SQL Server. Um serviço disponível fará o tratamento das informações, análise promocional, descontos e formas de pagamento e irá inserir as informações no MongoDB, exatamente no formato desejado para trabalharmos as telas de navegação e detalhe de produtos. Todas as alterações de catálogo que possam vir a existir antes da próxima integração será realizada no SQL Server e replicada apenas no registro equivalente no MongoDB.
Como será realizado o deploy?
Como o projeto será publicado em um Web Farm, a nossa preocupação era sobre a replicação das informações do MongoDB através dos servidores. Porém, o MongoDB oferece replicação, onde um servidor pode trabalhar como principal (master) e os dados são replicados para outros servidores (slaves). Veja mais em http://www.mongodb.org/display/DOCS/Replication
Conclusão
Na nossa experiência real com MongoDB, ficamos extremamente satisfeitos com os resultados. Até o momento, nosso objetivo de aumentar performance e criar um ambiente livre de schemas tem se mostrado atingido.
Abraços!
Olá pessoal!
Dando uma lida nas melhorias de performance da plataforma .NET 4.5, me deparei com algo extremamente interessante: Multicore Just-in-Time (JIT).
A teoria é muito simples: por que não utilizar vários núcleos para a compilação JIT? Além disto, será que seria possível compilar os métodos em uma determinada ordem, onde os primeiros fossem aqueles com maior probabilidade de execução?
Isto parece meio loucura mas é o que o Multicore Just-in-Time (JIT) faz. E o melhor de tudo, de uma forma extremamente simples.
As aplicações ASP.NET 4.5 já o fazem por default. Em outras ocasiões, basta executar duas linhas de código: uma indicando a pasta onde o arquivo que armazenará o profile ficará, e a outra para iniciar o procedimento. Este profile é o arquivo responsável por armazenar a ordem de compilação dos métodos, para que aqueles com maior chance de serem executados mais cedo sejam compilados antes.
Código para este processo:
ProfileOptimization.SetProfileRoot(@"C:\ProfileRoot");
ProfileOptimization.StartProfile("profile");
Esta otimização na compilação só será notada após a criação do profile. Portanto, na primeira vez nada será percebido.
Ao final do processo, um arquivo com o nome escolhido (no caso profile) será criado, na pasta indicada como root:
Fica a dica!
Abraços!
Olá pessoal!
Este ano de 2010 foi realmente muito bom. A NBR cresceu consideravelmente, eu tive algumas mudanças no meu trabalho, me casei, comprei um apartamento e tudo mais.
Definitivamente, este ano ficará marcado para sempre.
Fiz diversos amigos, dentro da comunidade Microsoft também.
O melhor ainda é que as perspectivas para 2011 são ainda mais positivas. E pelo que estou vendo, este sentimento é comum a muitos amigos por aí, o que me deixa mais feliz ainda.
Sem mais, desejo a todos um feliz ano de 2011, que muitos objetivos e conquistas sejam alcançados. Indepentende de tecnologias, linguagens ou religiões, que cada um faça o seu melhor, para garantir o melhor a sua volta.
Espero que todos sigam duas palavras: MUDANÇAS e EMPREENDEDORISMO.
Um forte abraço a todos e até ano que vem!
Olá pessoal!
Hoje o assunto não é código, mas sim a qualidade dele.
Recentemente aqui na NBR começamos com um cliente um contrato de manutenção e migração de 2 projetos existentes.
A nossa surpresa aconteceu quando tivemos acesso ao código-fonte dos projetos. E aí entra o assunto deste post…
Quão importante é a qualidade do código-fonte nos projetos?
A grande questão aqui neste caso específico é a seguinte: o layout é aceitável, planejado, onde pudemos perceber certa preocupação. Mas e o código por trás? Entre GoTo, banco de dados em Access, MySql e SQL Server no mesmo projeto (sem necessidade), abordagem 100% procedural, sem reutilização de código e ambientes dinâmicos, este post é mais um desabafo e uma preocupação do que qualquer coisa.
Nós como desenvolvedores natos temos que ter uma preocupação básica: estou fazendo meu trabalho corretamente ou estou me livrando dele?
Muitos clientes não analisam o código por trás dos seus projetos. Basta a interface cumprir o que foi prometido (ou quase cumprir) que está tudo certo.
E qual é o preço de um código mal feito?
A manutenção é tão importante quando o desenvolvimento de um novo projeto. O ponto mestre é defender isto para os possíveis clientes e provar, para os já clientes, que isto tem valor.
No nosso dia-a-dia tentamos apresentar aos clientes (quando eles estão interessados) que nosso código é bem feito. E isto não depende do projeto, do cliente ou do desenvolvedor: uma interface bem feita é tão importante quanto seu código. Qualquer um dos dois pode acabar com seu projeto.
Mas confesso que o mais dificil nisto tudo é defender que a qualidade tem preço e a sua importancia, para aqueles clientes que acham que não é necessário.
Como você defende este ponto de vista?
Vamos deixar claro: software bem feito não é barato! E definitivamente não existe a opção “sem qualidade”.
Abraços!
Olá pessoal!
Hoje meu post é voltado para o produto Microsoft Commerce Server. Se você não sabe o que é, acesse http://www.microsoft.com/commerceserver.
Portais de Compra Coletiva estão na moda. O principal conceito deste tipo de negócio é a união de diversos compradores com o objetivo de atingir um mínimo esperado para usufruir de descontos em diversos produtos e serviços. Temos como exemplos o Peixe Urbano e o Cidade Oferta.
A questão é que, como estes modelos estão em alta, será que podemos adotar um produto robusto para aguentar a demanda crescente de acessos, com facilidade de manutenção e ferramentas de monitoramento?
O Microsoft Commerce Server se baseia, resumidamente, em quatro pilares, os básicos de qualquer e-commerce: Marketing, Pedidos, Clientes e Catálogo de Produtos.
A utilização do produto para Compra Coletiva poderia ser feita de diversas maneiras.
1. Cadastro de Produtos ou Serviços para Ofertas
O cadastro de produtos ou serviços para ofertas podem ser cadastrados utilizando o Catalog Manager, dentro de categorias pré-determinadas. No exemplo abaixo, foi criado um catálogo chamado “Compra Coletiva”, com uma categoria “Gastronomia” e o produto/oferta “Jantar Especial de Natal”. Nesta sugestão, seria possível cadastrar inúmeras ofertas, separadas por categorias, e depois ativá-las utilizando o Marketing Manager.
A imagem abaixo demonstra a criação de variantes, para os casos onde a oferta pode conter variação de definição.
Por exemplo: imagine que uma determinada oferta pode oferecer em um modelo completo e um modelo simples. Seria possível criar uma oferta apenas, mas o usuário poderia selecionar qual modelo da oferta gostaria de comprar:
Algo muito importante é a definição do estoque. É possível editar um estoque por variant, o que nos ajuda a controlar o máximo e mínimo de vendas possíveis da oferta.
2. Divulgação das ofertas em tempo pré-determinado
A divulgação da oferta poderia ser através do Marketing Manager. Para isto, poderiamos criar uma definição de anúncio, e configurar sua propriedades para a data de publicação, tipo de anúncio, tamanho, imagens e cliques.
3. Integração com Formas de Pagamento
A forma de pagamento pode ser configurada através do Customers and Orders Manager. Poderíamos criar uma forma de pagamento PagSeguro, que teria uma pipeline para ser executado e que pudesse realizar a integração com o gateway.
Conclusão
Fica claro que a ferramenta possibilita diversas abordagens para as Compras Coletivas. Esta é apenas uma sugestão para demonstração do potencial da ferramenta.
Conheça mais sobre os recursos do Commerce Server, sobre o potencial de um application server como este, sua API, as questões de segurança, monitoramento e integração com outros produtos da Microsoft.
Acesse: www.commerceserver.com.br e www.microsoft.com/commerceserver.
Abraços!
A linguagem C# 4 apresenta um novo namespace capaz de interagir com a localização do computador, obtida através de recursos como GPS, Wi-fi, etc. A API é extremamente simples, e possibilita facilmente a criação de qualquer aplicação que trabalhe com estes recursos.
No Windows 7, um aplicativo como Geosense pode fazer este trabalho informativo.
Sobre a API
O namespace System.Device.Location é o ponto inicial. A classe GeoCoordinateWatcher é a responsável por obter as informações de localização:
static void Main(string[] args)
{
var wacther = new GeoCoordinateWatcher();
wacther.Start();
while (wacther.Status == GeoPositionStatus.NoData)
{
Thread.Sleep(10000);
wacther.Start();
}
Console.WriteLine(wacther.Position.Location.Latitude);
Console.WriteLine(wacther.Position.Location.Longitude);
Console.ReadLine();
}
É interessante notar que qualquer interação com o sensor de localização dentro do Windows 7 é registrada. O primeiro ícone mostra que houve interação, e serve de link para a visualização do log de atividades:
Abraços!
Olá pessoal!
Depois de bastante tempo sem publicar por aqui – afinal tive meu casamento, lua de mel, projetos indo pro ar, etc, etc – resolvi fazer um post sobre algo que utilizamos em um projeto recente da NBR.
Para aqueles que estão pensando em utilizar uma solução de pagamento online, o PagSeguro é uma ótima opção. Porém, sua documentação para integração com ASP.NET MVC, ou qualquer outra linguagem, não é 100%.
Por este motivo, este post servirá como guia para utilização com ASP.NET MVC, mas poderá servir de base para utilização em qualquer outra plataforma.
Como o objetivo aqui não é apresentar o PagSeguro, acesse seu site para conhecer o funcionamento.
1. Qual é o fluxo do PagSeguro?
O fluxo do PagSeguro é simples. O site que está vendendo algum produto ou serviço deverá enviar ao PagSeguro as informações da compra, como quantidade, produto, frete, etc. Este “envio” pode ser realizado como um post para um endereço do PagSeguro. A partir deste ponto o usuário estará no ambiente da UOL, onde deverá realizar um rápido cadastro, selecionar a forma de pagamento e concluir o processo. Neste momento, o PagSeguro pode ser configurado para retornar para uma URL específica do seu site, e consequentemente apresentar uma mensagem específica de retorno para o usuário.
Portanto, resumidamente podemos colocar:
- Seu site obtém as informações de compra, monta um formulário e envia-o para a URL do PagSeguro;
- O PagSeguro inicia o processo de pagamento, requisitando o cadastro do usuário (não é o mesmo cadastro do seu site);
- O cliente, já no ambiente do PagSeguro, solicita a forma de pagamento desejada;
- O usuário insere as informações e conclui o processo;
- O PagSeguro retorna para o seu site através da URL de retorno configurada no PagSeguro pelo administrador da conta;
- Em um outro momento, que não exatamente no retorno para a sua URL configurada, o PagSeguro chama a mesma URL passando informações via POST sobre o status da compra.
Em muitas conversas encontro dúvidas no passo 6. A mais comum delas é se o PagSeguro, ao retorna para a sua URL de retorno no fluxo do cliente, já envia as informações sobre o status da compra. Neste caso não, pois ele executa o verbo GET na sua URL. Quando, para esta mesma URL, ele executar o verbo POST, estará passando as informações da compra.
2. Como realizar sua implementação no ASP.NET MVC?
Portanto, se através da mesma URL configurada no PagSeguro, teremos o retorno da navegação do cliente no processo de compra e o recebimento das informações do status da compra, no ASP.NET MVC basta criarmos duas actions em um controller, uma configurada para GET e outra para POST.
1: public ActionResult Retorno()
2: { 3: // ...
4: }
1: [HttpPost]
2: public ActionResult Retorno(FormCollection form)
3: { 4: // ...
5: }
O primeiro método deverá retornar uma tela informativa ao cliente, informando, por exemplo, o status da compra dele.
O segundo método deverá obter as informações do FormCollection e tratá-las no sistema, para atualização do status do pedido. É importante destacar que a cada alteração do status do pedido dentro do PagSeguro, uma requisição para a URL de retorno através de POST será realizada.
É muito importante também citar que apenas a requisição ao GET é síncrona, dentro do fluxo de navegação do cliente. Já para a outra requisição não podemos determinar quando será realizada.
Porém, no projeto que utilizamos a solução, o retorno via POST do pagseguro é extremamente rápida, e em alguns momentos o retorno do GET já apresenta um status atualizado para o cliente.
3. Como testar localmente?
Um grande problema deste esquema é a dificuldade de testes. No projeto que publicamos, realizamos dois tipos de teste para o PagSeguro. Em um, no período de desenvolvimento, o nosso fluxo de compra não chega ao PagSeguro, paramos no momento em que a compra é registrada no sistema com o status “Registrado”. Neste ponto, ativamos um HTML simples nosso, que simula o retorno do PagSeguro à nossa action Retorno configurada como POST, passando as informações necessárias.
Em produção, toda comunicação de retorno com o PagSeguro é logada no banco de dados. Gravamos todas as chaves/valores que chegam via POST para análise da comunicação.
Conclusão
O PagSeguro é uma ferramente excelente. Sua documentação e ambiente de teste não estão OK, mas seu funcionamento e agilidade compensam tudo isso.
Abraços.
Neste último mês estive envolvido com um evento de grande porte em Londrina e Maringá, voltado ao público jovem. No geral, nossa estimativa era receber 4500 pessoas, divididas em 3 dias, sendo o primeiro em Maringá e os outros dois em Londrina.
Eis que surge, em uma decisão arriscada e corajosa, o motivo deste post: a divulgação deste evento foi 80% focada na web.
A estratégia foi simples: atingir o público-alvo deste evento onde ele mais se encontrava: orkut, facebook, portais e twitter.
Cito que a decisão é arriscada e corajosa pois decidir por utilizá-lo somente, sem associar televisão + rádio + outdoor + etc é muito complicado. Defender a idéia e mudar a nossa cultura não é tão simples como “o twitter tá bombando, põe lá”.
Você arriscaria a divulgação deste evento só nas redes sociais?
Talvez se você for um frequentador assíduo destes canais não deva estar espantado. Porém, eu estou.
Qual é o futuro das mídias? Será que temos, neste exato momento e em alguns nichos, a inversão completa dos papéis, quando nos referimos aos veículos de divulgação? E para todos os públicos, será este um caminho inevitável?
O que você acha?
Para termos um comparativo, este mesmo evento foi realizado no ano anterior, com a realização de rádio + televisão. E aqui está o dado interessante: as vendas deste ano foram mais rápidas, com um “bum” maior.
Ah, a conclusão do evento:
- 4.555 ingressos vendidos (100%)
- Vendas encerradas 5 dias antes do previsto
- Impacto nas vendas facilmente percebido pela divulgação via Twitter
- Procura de ingressos até o início do evento
Abraços!
More Posts
Next page »