October 2009 - Posts
Para entendermos completamente o que é o novo Commerce Foundation, precisamos relembrar alguns conceitos.
Como podemos observar na figura, a estrutura base do Commerce envolve o que chamamos de Commerce Server Core Systems, que pode ser subdivido em 5 sistemas:
-
Orders System
-
Marketing System
-
Catalog System
-
Inventory System
-
Profiles System
Conforme explicado no post anterior, cada sistema representa uma parte importante no processo do comércio eletrônico, e em conjunto fornecem toda a estrutura necessário que criemos, através do Commerce Server, uma aplicação completa.
A versão 2009 apresentou um novo conceito chamado Commerce Foundation, que podemos definir basicamente como:
No cenário técnico, o Commerce Foundation é uma coleção de novas operações que podem ser realizadas nos Core Systems, como segue:
Catalog System
-
Recuperação de informações do site, catálogo, categorias, produtos, variantes e estoque;
-
Full-text search;
-
Integração com Sharepoint;
Marketing System
-
Recuperação de conteúdo direcionado;
-
Recuperação dos descontos aplicados ao carrinho ou ao pedido;
-
Recuperação de descontos simples aplicados a produtos ou categorias;
-
Registros de eventos de campanhas;
-
Integração com Virtual Earth;
Orders System
Existem algumas diferenças entre a versão 2009 e versão 2007 do Orders System. Neste novo modelo, algumas alterações foram efetuadas em relação ao basket e principalmente nas formas de pagamento. Veremos os detalhes nos próximos posts da série.
Profiles System
Através deste sistema é possível administrar as informações dos usuários, através de Site Terms e Profiles, assuntos próximos da série de posts sobre Commerce.
Novo modelo de entidades
A versão 2009 do Commerce apresentou um novo modelo de entidades para representar a visão conceitual do produto através de todos os Core Systems. A base para todo este novo modelo de entidade é a classe CommerceEntity.
Todas as operações realizadas no Commerce podem ser resumidas como operações de request-response. Resumidamente, podemos enviar dados para a requisição e receber respostas de execução.
var query = new CommerceQuery<CommerceEntity>("UserProfile");
query.SearchCriteria.Model.Properties["Email"] = "useremail@yourcompany.com";
CommerceResponse response = OperationService.ProcessRequest(base.GetCurrentRequestContext(), query.ToRequest());
A figura acima representa a entidade base CommerceEntity, apresentando a coleção Properties. Esta coleção representa um conjunto nome/valor para as propriedades da entidade.
OperationService
O serviço de operações exemplificao acima tem o papel de receber uma requisição do Commerce e retornar uma CommerceResponse.
CommerceRequest e CommerceResponse
O objetivo do CommerceRequest é simplesmente identificar uma ou mais operações a serem realizadas, sendo que o CommerceResponse é a resposta para estas operações:
Pontos Positivos desta Abordagem
O que vem para agradar e muito é o novo modelo totalmente extensível, fornecendo entidades fortemente tipadas definidas de acordo com cada projeto, através da interface ICommerceEntity:
--
Veremos nos próximos posts a aplicação prática destes conceitos. Aguardem!
Para você que está chegando diretamente neste post, esta é uma série dedicada ao Commerce Server e detalhes da versão 2009 do produto. Outros posts já foram publicados:
- Microsoft Commerce Server: O que é?
- Microsoft Commerce Server: Como saber que é uma boa decisão?
Nesta publicação vou falar um pouco sobre a estrutura que o desenvolvedor encontrará no Commerce Server 2009.
O que preciso saber antes de desenvolver para o Commerce?
Antes de iniciar a prazerosa tarefa de desenvolver para o Commerce, temos que conhecer as frentes disponíveis.
Dentro do produto podemos agir através da criação da aplicação e de sua base, pipelines, integração com sistemas de pagamento, ou personalizando e extendendo a parte de pedidos. Se quisermos deixar ainda mais completa esta tarefa, podemos incluir a integração com Biztalk, que falaremos futuramente.
Inicialmente vamos entender a visão da aplicação direta e de seus fundamentos, para então partir para outras frentes de desenvolvimento.
Estrutura Básica do Commerce
Pensando de uma forma extremamente simples, o nosso objetivo aqui é conseguir criar uma aplicação que disponibilize um catálogo de produtos e realize a venda para os consumidores. Analisando desta maneira, podemos identificar três módulos que estão presentes no Commerce: Catalog System, Orders System e Profile System. Como o próprio nome diz, são módulos responsáveis pelo catálogo de produtos, os pedidos realizados ou não, e todos os clientes (cadastrados ou anônimos) que interagem com a aplicação.
Além disso, o Commerce conta com um módulo específico de Marketing, criando oportunidades para promoções ou conteúdos direcionados.
Em uma visão mais abstrata, podemos definir toda a estrutura do Commerce da seguinte maneira:
onde nosso foco neste momento são os Commerce Server 2009 Core Systems.
CS Core Systems: Arquitetura
A figura abaixo resume a arquitetura do que chamados de Core Systems do Commerce Server:
Nosso foco aqui é para a visão do desenvolvedor, portanto vamos entender a parte em destaque acima.
Primeiro conceito que podemos concluir é que o Commerce é baseado em 5 e não 4 sistemas como dito anteriormente, a seguir:
- Orders: responsável por tudo que é relativo a pedidos, concretizados corretamente ou não.
- Marketing: módulo específico para criação de campanhas, como descontos, leve 2 pague 1, etc.
- Catalog: responsável por todas as informações dos produtos e suas variantes.
- Inventory: responsável pelo estoque.
- Profiles: responsável pelas informações dos usuários.
O Inventory System é responsável por todo o estoque, seu estado atual e histórico, e em conjunto com o Catalog System completa todas as nossas necessidades para o e-commerce.
Com estes 5 sistemas definidos, podemos utilizar o Commerce Server .NET API para, através da nossa aplicação ASP.NET, tornar nossa aplicação “utilizável”.
Observem que é possível utilizar o Biztalk Server para integrações com LoB, como ERP e CRM, com adaptadores nativos para o Commerce. Mas isto é um assunto dedicado ao final da série de posts :)
Uma primeira observação importante aqui é que ao desenvolver para o Commerce devemos esquecer daquele velho companheiro chamado Banco de Dados (pelo menos inicialmente). Na nossa aplicação o Commerce é o responsável pelo acesso aos dados. O nosso trabalho como desenvolvedor é manipular apenas os objetos, deixando os detalhes da persistência para o Commerce Server Manager.
--
No próximo post vamos analisar como é desenvolver para o Commerce na prática ;)
Até lá!
Uma das grandes dificuldades do Commerce é conseguir avaliar em quais situações este produto é uma boa decisão para utilização. Este post irá apresentar algumas diretrizes para verificar se adotar o Commerce Server irá trazer benefícios ou não, e a qual custo.
A Primeira Impressão
Se você iniciou uma pesquisa para saber se o Commerce Server é bom ou não, com certeza você passou pelo site http://www.microsoft.com/commerceserver.
Ao acessar a página, você logo clicou no lado direito, onde diz “Product Overview: Learn how Commerce Server 2009..”. Estou certo?
A primeira impressão que o produto passa pela sua descrição é que é uma loja pronta que exige pouca implementação. É aí que mora o perigo: não se engane, a vida não é assim tão fácil.
O Commerce Server nos fornece a base de desenvolvimento para projetos de comércio eletrônico. Isso não quer dizer, de maneira nenhuma, que é so pegar o projeto padrão e colocar no ar, criar os produtos e sair vendendo. São raros os casos em que isso é possível.
Frases e comentários do Overview do produto
“it comes with a new, production-ready, out-of-the-box, contemporary Web site that allows businesses to get their stores live and merchandise moving more quickly”
Não leve isto em consideração ao decidir utilizar o produto. Os casos destas frases são aqueles raros em que seu comércio eletrônico não precisa ser integrado com nada, não exige regras de negócio específicas e não expõem uma série de serviços. Normalmente você precisará customizar o projeto, ou então criar um novo para que adapte aos padrões de desenvolvimento da empresa.
Outro ponto importante sobre o Commerce é sua instalação, que exige inúmeros detalhes e leva uma certo tempo para finalizá-la.
É importante ressaltar que se o seu comércio eletrônico é simples e não exigirá customizações, o site padrão servirá corretamente, sem dificuldades alguma. Porém, isto é muito raro de acontecer.
“Commerce Server 2009 enables fast and easy information-editing and smooth content management with workflow approvals with Microsoft SharePoint Commerce Services”
A versão 2009 do produto conseguiu unir o poder do Sharepoint com a base do Commerce Server. Se você conhece Sharepoint sabe que este é um ponto que traz inúmeros benefícios e facilidades.
“Using the new Default Site and skinning features of Commerce Server 2009 helps you get your site up and running promptly, so you can start selling right away”
Caimos novamente naquele primeiro caso.
“Reduced Costs in Site Development and Deployment”
Sim, esta frase é correta. Apesar de não conseguirmos utilizar o template padrão (95% dos casos) para colocar um projeto no ar, o Commerce reduz e muito os custos de desenvolvimento e publicação, além de fornecer a segurança de um produto Server da Microsoft.
Ao fornecer um imenso framework para catálogo de produtos, marketing, clientes e pedidos, o Commerce Server permite que a empresa foque nos detalhes essenciais do projeto, como regras de negócios, integrações e segurança. Não precisamos nos preocupar em criar a base de comércios eletrônicos visto que isto já está preparado (e muito bem preparado).
Sobre a publicação, o Commerce Server permite que realizemos esta tarefa através de recursos simples e direto. Criar um pacote para levar até o servidor, ou então replicar este pacote pelo seu Web Farm é muito simples.
Equipe Especializada na Ferramenta
Outro ponto importante ao adotar a ferramente é saber se o mercado fornece os profissionais técnicos especializados.
Como os projetos no Brasil ainda são poucos (em relação ao total de projetos grandes de e-commerce), existem poucos profissionais disponíveis para os projetos, o que podemos concluir:
- Os que existem são caros;
- Os projetos existentes absorvem os profissionais do mercado;
Tomando a decisão…
Este post tem o objetivo de ajudar na decisão pelo Commerce, sem se iludir com os textos do site. As observações colocadas permitem que o tomador de decisão saiba o que irá enfrentar, positivamente ou não, antes de iniciar o projeto.
Perguntas básicas:
Pra qual tipo de projeto o Commerce é ideal?
Na minha opinião, o Commrece Server é adequado para qualquer tipo de projeto, de qualquer tamanho. Não existe uma questão técnica clara de que o Commerce serve apenas para grandes ou pequenos projetos. Existe apenas a questão do investimento e do retorno ao analisar o custo dos profissionais, o custo da licenças, infra-estrutura, etc.
Qual é o preço por hora (em média) de um desenvolvedor especialista em Commerce?
Um desenvolvedor especialista em Commerce recebe em média R$40,00 ~ R$50,00 por hora.
Em diversas regiões no mundo as regras padrões de comércio eletrônico são diferentes. O template padrão é voltado para qual região do país?
O template padrão do Commerce foi desenvolvido para os Estados Unidos. Isso quer dizer que alguns detalhes de pagamentos, entregas, parcelamento e juros não estão implementadas por padrão.
Existe documentação na internet?
Existe e é bem completa. Este endereço http://www.microsoft.com/commerceserver/en/us/Pricing-Licensing-FAQ.aspx apresenta uma série de perguntas e respostas que ajudarão na tomada de decisão.
História
Assim como outras empresas grandes do setor, a Microsoft investiu (e continua investindo) esforços na área de comércio eletrônico, fornecendo produtos exclusivos para este ramo.
Em outubro de 1996 a Microsoft liberou o Merchant Server, uma solução para o então ainda recente mercado de B2C. Inicialmente este produto pertencia a uma empresa chamada eShop, sendo baseado em Python e C++.
Com o lançamento do ASP (Active Server Pages) em Dezembro de 1996, o processamento principal do Merchant foi migrado para objetos COM.
Mas a promissora vida do Merchant Server foi encerrada logo na primeira versão, quando a partir daí começou a ser incorporado na versão “Commerce Edition” de um produto chamado Site Server versão 2.0. Na sua versão seguinte 3.0, algumas funcionalidades de administração dos conteúdos do e-commerce e também outros conteúdos comuns foram adicionadas.
Ao descontinuar o Site Server, a Microsoft criou duas novas linhas de produtos: Commerce Server, com toda sua linha voltada para o e-commerce; e o Sharepoint, com a administração do conteúdo.
O Caminho do Commerce Server
A versão inicial do Commerce Server surgiu em 2000, quando o Site Server deixou de existir. Algumas mudanças ocorream e em 2002 foi lançada uma nova versão, seguinda de alguns Services Pack em 2003, 2004 e 2006, quando a versão 2007 do produto já estava em desenvolvimento.
A penúltima versão do produto, Commerce Server 2007, trouxe muito benefícios, tornando-o mais competitivo e utilizado no mercado.
Em março de 2009 foi lançada a versão mais atual (no período de publicação deste post). Inicialmente conhecida como “Mojave”, a versão 2009 adicionou recursos sobre a base do 2007, como múltiplos canais de publicação, utilização do Sharepoint para gerenciamento, mais de 30 web parts por padrão, o Commerce Server Foundation, etc.
Fontes de Informações
A versão 2000 e 2002 do Commerce contaram com a publicação de alguns livros, o que na época era fundamental pelo dificil acesso à informação.
A versão 2007 não conta com nenhuma publicação, tornando os blogs e acesso online a base para a disseminação do conhecimento. A partir desta versão foram criados fóruns no MSDN, que podem ajudar na resolução de problemas.
Mesmo assim, o Commerce continua sendo um mito para muitas empresas, que pela dificuldade de encontrar pessoal especializado deixa de adquirir o produto.
O Commerce Server no Brasil
No Brasil o Commerce começou a ser largamente utilizado a partir de 2007. Antes disso, poucos projetos utilizaram o produto.
Atualmente temos empresas como Grupo Pão de Açucar e BM&F Bovespa que adotaram esta base para seus negócios em comércio eletrônico.
Existe um grupo de usuários chamado Commerce Server Brasil que reúne um grupo de profissionais especializados na ferramente, onde é possível trocar idéias, soluções, vagas de emprego, etc.
E agora?
Nos próximos posts vou escrever mais detalhes sobre a versão 2009, além de questões como migração, problemas encontrados ao tentar vender e aplicar o Commerce, entre outros pontos interessantes.
Abraços!
Quem me acompanha pelo twitter sabe do meu descontentamento com a Locaweb. Nos últimos meses tenho enfrentado problemas no serviço de e-mail, quedas temporárias no SQL Server e inúmeras inconsistências nos servidores Windows 2008 com aplicação ASP.NET MVC.
O mais interessante de tudo é ainda ter um blog para acompanharmos os problemas, o que – dependendo do caso – passa a ser uma declaração de incompetência do que um serviço ao cliente, justamente por causa do volume de problemas.
Por esses motivos resolvi entrar em uma árdua luta a favor daquela famosa premissa que os serviços de hospedagem prometem quando os contratamos: 99,8% do tempo funcionando.
Pesquisando rapidamente encontrei o UOL Host, um host que disponibiliza as principais características de meus clientes – Windows Server 2008, SQL Server 2008, ASP.NET MVC, etc, etc.
Análise do UOL Host
Rapidamente resolvi criar uma conta para efetuar alguns testes. Em menos de 5 minutos estava com tudo criado, e em menos de 15 com tudo funcionando (sem replicação de DNS, apenas pelos endereços temporários). Logo após comecei a efetuar os testes nas bases, FTP, e-mail, web e painel de controle.
FTP
O FTP funcionou corretamente, e com uma performance maior que o meu serviço na Locaweb (média de 13% mais rápido, tanto para Upload quando para Download). Até aí tudo bem, este valor não pode ser levado em consideração.
Mas o que eu mais fiquei impressionado é que em vários momentos a Locaweb pecou no funcionamento, alternando muitas vezes entre um funcionamento 100% e performance ruim.
E-mail
Este era meu maior problema da Locaweb. Inúmeras vezes ao dia o serviço de e-mail parava de funcionar, o que chegou a impactar várias horas de trabalho. Isto não acontecia uma vez ao mês, mas sim várias vezes por semana, tanto para e-mails enviados como recebidos.
O serviço do UOL, em 2 semanas de utilização não parou nenhum momento.
Web
A performance das duas opções funcionou bem. Porém, em uma determinada área da aplicação, o mesmo código ASP.NET MVC + jQuery não funcionou na Locaweb e no UOL sim, ambos em servidores Windows 2008.
Mas no geral este item pode ser declarado como empate :)
Painel de Controle
O painel de controle de ambos é muito produtivo, com todas as funcionalidades ok.
Um ponto positivo do painel de controle do UOL é que tanto o gerenciamento da web/banco como do e-mail fazem parte do mesmo sistema, já na Locaweb são sistemas diferentes.
Um ponto positivo da Locaweb é a criação de subdominios diretamente no painel, o que no UOL ainda depende de help desk. Meus pedidos para criação de subdominio foram atendidos em menos de 1 hora, mas ainda sim isto é um problema.
Relatórios de Acessos
Um item muito importante a analisar são os relatórios de acesso dos sites. Neste quesito a Locaweb ganha em disparada, com seu Urchin.
O relatório do UOL Host apresenta os dados corretamente, mas a interface e a interação não são tão produtivos quanto da Locaweb.
SQL Server
Neste item a UOL Host ganha novamente, somente por causa da performance. Todos os outros itens (recursos, acesso, gerenciamento, segurança) são iguais.
Atendimento
Tão importante quanto o funcionamento correto é atendimento de suporte. Simulei alguns problemas básicos na minha hospedagem e entrei em contato, tanto pelo Help Desk como pelo Chat, em ambos os hosts. Todos os atendimento foram realizados corretamente, em um tempo relativamente bom.
Conclusão
Esta análise é apenas o resultado de uma experiência rápida, que não leva em consideração a estrutura dos data centers, segurança das informações, backup diário, etc.
Este post resume as funcionalidades básicas de quem utiliza a hospedagem de terceiros para clientes, e precisa de segurança na hora escolher o fornecedor.
Vou continuar fazendo estas comparações, visto que tenho aplicações nos dois servidores.
Publicarei as novidades :)
Abraços.
Update 1 21/10/2009 17:10: Acabei de receber uma ligação do UOL Host para saber o que estou achando do serviço, quais são as minhas percepções até agora, sugestões, críticas, etc. Muito legal!
Update 2 25/03/2010 08:55: Estou voltando para a Locaweb. Toda hospedagem deve ser completa, tanto em performance quanto em atendimento. Prefiro voltar para um lugar que tenha uma performance 90% e atendimento 100% ao invés de manter meus 95% de performance e 0% de atendimento. Pois é.
Update 3 29/03/2010 11:20: Não consegui voltar para a Locaweb. Em alguns minutos tive problemas também. Então vamos manter UOL Host, visto que depois das reclamações tive um atendimento exemplar.
Sobre o jQuery
Apesar de ser um dos mais comentados “lançamentos” dos últimos anos, muita gente ainda não sabe e não tem prática com jQuery. Mas o mais legal disso é que o jQuery não tem nada de novidade por baixo dos panos.
Basicamente, jQuery é um projeto resultante da soma do CSS, com seus seletores, e das possibilidade do Java Script, tudo isto escrito em uma nova linguagem, um novo idioma.
Para exemplificar, em um passado não muito distante, desenvolver a comunicação Ajax era algo complicado. Exigia-se muitas linhas de código, enfrentava-se dificuldade com testes, com retornos, etc. Hoje, com jQuery, é possível utilizar seus recursos “prontos” mantendo a preocupação nas regras do negócio ao invés da estrutura técnica para realizá-las.
A única questão diferente (diferente.. não dificil) é que exige uma sintaxe um pouco fora da usual tanto para desenvolvedores quanto para designer, pois mistura um pouco dos dois mundos ao utilizar seletores CSS com sintaxe baseada no ECMA 262. Fora isso não tem segredo, não é difícil e facilita muito a nossa vida.
Como o foco deste post não é o jQuery, recomendo que acesse o http://jquery.com para obter mais informações.
Sobre o JSON
Com o foco dado ao à comunicação assíncrona na web nestes últimos tempos, surgiu a necessidade de utilizarmos um formato prático para troca de informações entre as bibliotecas baseadas no ECMA 262 e códigos server-side. Neste cenário entra o JSON – JavaScript Object Notation.
O JSON nada mais é do que uma definição de nome/valor para representação de informações. Os “objetos” são representados através da estrutura abaixo:
Como é possível imaginar, a iteração nestes objetos deve ocorrer facilmente, visto que não há tipagem, regras ou qualquer outro detalhe que aumente a complexidade no acesso às informações.
O benefício ocorre quando unimos a facilidade do JSON com a produtividade do jQuery, como no exemplo abaixo:
$.getJSON("/Graficos/Obter",
function(data) {
if (data == '' || data == null) {
jAlert("Não foi possível obter os dados para visualização da tabela.");
return;
}
else {
$(eval(data)).each(function() {
// Execução
});
$("#planilha").dataTable({});
}
});
Se algo parece estranho, com certeza você não está habituado ao jQuery.
Como podemos perceber pelo exemplo, a sintaxe é extremamente simples. No exemplo acima, a instrução getJSON retorna de uma URL uma série de informações no formato JSON explicado acima. Através das informações retornadas (data), é possível criar uma laço (.each) onde podemos percorrer cada elemento e efetuar uma execução.
Na prática, um código em JSON tem o seguinte formato:
{"id":1,"nome":"Nobre"}
Uma coleção de objetos apresenta colchetes para delimetar os itens pertencentes à coleção:
[{"id":1,"nome":"Nobre"},{"id":2,"nome":"André"}]
E como isto se encaixa do ASP.NET MVC?
No ASP.NET MVC não existe requisições mapeadas a arquivos físicos, mas sim a métodos que retornam algum tipo de informação para o usuário, que utilizam como base a classe ActionResult. Em alguns casos, este retorno pode ser uma ViewResult (telas aspx, por ex), um JavaScript, ou então um Json.
O ActionResult Json permite que objetos sejam “automaticamente” transformados para o padrão JSON, e esta transformação seja retornada para o autor da requisição.
O exemplo abaixo demonstra o resultado da transformação de um objeto extremamente simples:
public ActionResult Index()
{
var teste = new object[]{ new { id = 1, nome = "Nobre"}, new { id = 2, nome = "André" }};
return Json(teste);
}
Tá… e tem algum exemplo mais prático?
Em uma cenário mais real, esta abordagem poderia ser utilizada em uma interface com comunicação assíncrona, visando a troca de dados entre o código jQuery e o servidor. É possível executar o getJSON diretamente em um Controller, usufruindo ainda da possibilidade de retornar uma ActionResult Json ou ViewResult dependendo do tipo de requisição:
No Controller:
public class GraficoController : Controller
{
public ActionResult Padrao(string contexto, string tipo, string formato)
{
IList<IItemGrafico> dados = new GraficosPadraoRepository().ObterDadosParaGraficoPadrao(contexto);
if ("json".Equals(formato, StringComparison.CurrentCultureIgnoreCase))
{
return Json(dados);
}
...
return new FileStreamResult(builder.Exportar(), "image/png");
}
No ASPX:
$.getJSON("/Grafico/Padrao?formato=json",
function(data) {
if (data == '' || data == null) {
jAlert("Não foi possível obter os dados para visualização da tabela.");
return;
}
else {
$("#planilha tbody").html("");
$(eval(data)).each(function() {
$("#planilha tbody").append("<tr><td>" + (this.Empresa != null ? this.Empresa : "") + "</td><td>" + this.Item + "</td><td>" + (this.Item2 != null ? this.Item2 : "") + "</td><td class=\"center\">" + this.Valor + "</td></tr>");
});
$("#planilha").dataTable({});
}
});
Lembrando que “data” (parametro da function callback) armazena o resultado da requisição a /Grafico/Padrao em formato JSON. Observem a iteração através da função “each” do jQuery.
Conclusão
Apesar de muito rápido, este post demonstra a utilização conceitual e prática do jQuery e JSON, dentro do ASP.NET MVC.
Espero que tenham gostado!
Abraços!
No dia 05/10 (segunda-feira) fizemos o segundo dia do Londrina TechDay #2, com as palestras sobre Silverlight 3 (Márcio Fábio Althmann) e .NET 4.0 / Visual Studio 2010 (Carlos dos Santos).
O evento foi muito interessante no geral. No primeiro dia, realizado no campus da PUC em Londrina, os participantes puderam participar das palestras de ADO.NET Data Services, Azure e a palestra Microsoft e a Inovação, por Alexsandro Salmazo (Microsoft).
O segundo dia, com média de publico de 250 pessoas, apresentou as novidades da plataforma .NET e do Silverlight, com ótimos exemplos.
Em breve a equipe do Londrina TechDay fará uma onde de palestras sobre Windows 7, apenas para empresas.
Obrigado a todos pela presença e até o próximo!
Márcio Fábio sobre Silverlight 3
Carlos dos Santos sobre VS2K10 e .C# 4.0
Eduardo Spoky e André Nobre
André Nobre e Márcio Fábio
A equipe indo embora do evento… :)
Quarta-feira (30/09) tivemos o primeiro dia do Londrina TechDay, na PUC em Londrina.
Nesta primeira sequencia de palestras, Michel Banagouro falou sobre o ADO.NET Data Services e eu falei sobre Windows Azure.
Apesar do público reduzido em comparação com a primeira edição, as apresentações foram muito interessantes, e em certos momentos com bastante participação do público.
Pelos feedbacks positivos, o primeiro dia foi muito bom!
Aqui está minha apresentação:
Agradeço a presença de todos e não se esqueçam que hoje tem o segundo dia, na UNifil, com Carlos dos Santos (MVP) e Márcio Fábio (vencedor do WinThe7 – Desenvolvedores).
Abraços!
More Posts