Monique Monteiro

Aumentando a produtividade e automatizando o desenvolvimento com Software Factories: Web Client Software Factory

MoniqueLouise — Mon, 09 Jul 2007 06:59:00 GMT

(Aproveitando para tirar a poeira :) )

Para quem quiser saber um pouco sobre software factories, foi publicado um artigo meu no Linha de Código. O link é http://www.linhadecodigo.com.br/artigos.asp?id_ac=1360&pag=1 .

Neste artigo, é feita uma breve introdução ao conceito e é mostrada uma fábrica real: a Web Client Software Factory - voltada para desenvolvimento Web. Ao final, há uma lista de referências para quem tiver maior interesse no assunto.

Software factories

MoniqueLouise — Tue, 27 Mar 2007 09:33:00 GMT

Estou me aprofundando no conceito de software factories, muito difundido pelas novas ferramentas da Microsoft, a saber o DSL toolkit e algumas software factories que já foram lançadas: para smart clients, aplicações móveis, serviços, jogos, etc. Até inclui no meu hub uma enquete para ter uma idéia da utilização desse conceito em aplicações de médio ou grande porte. Quem estiver utilizando, fique à vontade para postar comentários, mensagens, etc.

Logoff no ASP.NET (complementando)

MoniqueLouise — Thu, 08 Mar 2007 14:15:00 GMT

Ainda com relação a logoff no ASP.NET, um complemento ao post anterior: antes de qualquer redirecionamento, esqueci de citar que deve ser chamado o método FormsAuthentication.SignOut(). Esse sim remove o ticket de autenticação do usuário. Recomendo ainda para quem for usar esse método que dê uma olhada em http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication.signout.aspx. Tem algumas questões de segurança que devem ser tratadas, para prevenir ataques de replay, como por exemplo salver o status do usuário em storage persistente.

Campos desabilitados no ASP.NET e AJAX

MoniqueLouise — Wed, 07 Mar 2007 17:47:00 GMT

Eis algumas dicas bem interessantes de um colega (Cleviton Monteiro) sobre ASP.NET e AJAX:

O IE não seta para cinza a cor de um campo que está desabilitado (enable = false). Portanto, para garantir que o usuário não vai ter problemas com usabilidade, devemos utilizar um estilo css para deixar o campo cinza. Isto é feito da seguinte forma:

- Criação de um estilo css no arquivo .css do projeto (ou verificar se já existe um);

- Quando desejar deixar o campo desabilitado, setar a propriedade "CssClass" do TextBox com uma string com o nome do estilo. Por exemplo: textBox1.CssClass = "disabled"; (onde disabled é o nome do estilo css).

Agora sobre AJAX:

- Problemas com componentes validators quando utilizados com ajax

Os componented de validação do ASP.NET 2.0 não funcionam com o AJAX RC. Segundo [1]:

"Microsoft is a bit behind in releasing a patch, via Windows Update, for ASP.NET 2.0. This patch would solve the UpdatePanel/Validator control issues that have cropped up in previous versions of ASP.NET AJAX (b1, b2, RC1)."

Para resolver o problema sem ser pelo windows update, os passos seguines devem ser seguidos:

- Copiar uma Validators.dll contida no bin do arquivo baixado em [3] para o bin do viewer;

- Colocar esse mapeamento no web.config:

</tagMapping>

Referencias interessantes sobre AJAX.

[1] http://209.85.165.104/search?q=cache:1IEMd4dhsssJ:devjunky.wordpress.com/2007/01/25/aspnet-ajax-rtm-validator-problems-anyone/+asp.net+ajax+validator&hl=pt-BR&ct=clnk&cd=9&gl=br

[2] http://weblogs.asp.net/scottgu/archive/2007/01/25/links-to-asp-net-ajax-1-0-resources-and-answers-to-some-common-questions.aspx

[3] http://blogs.msdn.com/mattgi/attachment/1516974.ashx

[4] http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx

Logoff no ASP.NET

MoniqueLouise — Wed, 07 Mar 2007 17:43:00 GMT

Ao utilizar o método FormsAuthentication.RedirectToLoginPage() após uma operação de logoff, ao logar novamente é retornada a página em que o usuário estava anteriormente à ação de logoff, e não a página principal da aplicação, como é o comportamento esperado. Isso ocorre porque esse método inclui um parâmetro ReturnUrl na query string, que contém o endereço da página em que foi feito o logoff. Para corrigir esse problema, deve-se utilizar ao invés o método Response.Redirect(FormsAuthentication.LoginUrl), que se limita a redirecionar para a tela de login configurada, sem incluir parâmetros adicionais na query string.

Datasets e table adapters

MoniqueLouise — Wed, 07 Mar 2007 17:36:00 GMT

Lá vão algumas descobertas com relação aos table adapters, uma novidade do ADO.NET 2.0 que permite utilizar adapters fortemente tipados:

- Ao criar queries em table adapters, percebi que sempre era necessário retornar sempre todas as colunas da query. Quando isso não era feito, era lançada uma exceção de integridade do banco. Vi isso em algum fórum, mas não encontrei uma explicação lógica.

- O Query Builder do Visual Studio pelo jeito não permite que se utilize a construção “in” do SQL.

- Ao fazer qualquer alteração no banco (criação de colunas, modificação do tamanho máxima das colunas), é necessário refeti-la no dataset tipado correspondente, ou recriar o dataset. Isso vale mesmo em situações onde o tamanho das colunas aparentemente não é relevante. Deve ser devido a checagens de integridade que são feitas pelo dataset.

Devido aos problemas citadaos acima, pessoalmente cheguei à conclusão que muitas vezes é mais produtivo usar ADO .NET diretamente, ao invés dos table adapters. Vamos aguardar o LINQ pra ver se será lançada uma solução adequada para mapeamento objeto-relacional.

Dicas de WCF

MoniqueLouise — Wed, 07 Mar 2007 17:27:00 GMT

Estou tirando a poeira do blog com algumas dicas resultantes de experiências que tive após o contato com o WCF em um projeto real (mais precisamente uma prova de conceito que deve evoluir para um sistema real). Foi um trabalho interessante, que envolvia um sistema amplamente distribuído, onde um requisito importante era justamente a independência de protocolo de comunicação.

Com relação às dicas, ou melhor, lições aprendidas, aí vão elas:

- Ao criar no Visual Studio um projeto que exponha serviços WCF que devam ser hospedados no IIS, utilizar o template Website à WCF Service. Esse template, por tratar-se de um projeto Web, evita problemas tais como criação de strings de conexão no próprio código compilado da aplicação, uma vez que o arquivo Web.config passa a ser usado para armazenar strings de conexão. Além disso, referências para outros serviços WCF também são acrescentadas ao Web.config, sempre que o proxy para algum serviço WCF seja criado/atualizado. Caso seja utilizado um template não-Web, essas referências são acrescentadas ao arquivo app.config, que não é reconhecido pelo IIS.

- Essa é bem útil: sempre que um serviço WCF retornar uma instância de ICollection, esta será representada no proxy para o serviço como um array. Sendo assim, no cliente, esse array deve ser tratado como array, e não como ICollection. Se continuar sendo tratada como ICollection, será gerado um erro de serialização.

- Ao lançar exceções em serviços WCF, não utilizar objetos que herdem de Exception, uma vez que o WCF não é capaz de serializar corretamente esses objetos. Ao invés disso, utilizar classes comuns para encapsular os dados do erro e lançar FaultException<classe do erro>, onde <classe do erro> é a classe criada. O construtor de FaultException recebe como parâmetro uma instância dessa classe. O serviço, por sua vez, deve declarar que lança tal erro através do atributo [FaultContract(typeof(<classe do erro>)]

- Existem situações em que se deseja gerar um proxy dinamicamente para um dado serviço, cujo contrato não é conhecido em tempo de desenvolvimento. Nesse caso, ao invés de usar o svcutil para gerar o proxy, pode-se usar uma ferramenta que a MS desenvolveu para esse cenário: o WCF Dynamic Proxy (http://wcf.netfx3.com/files/folders/development_tools/entry6148.aspx). Avaliei essa ferramenta e ela atende perfeitamente esse requisito, porém com algumas limitações: não é suportada chamada assíncrona ao serviço, e é gerada uma exceção ao invocar operações que recebam como parâmetro um array.

Por enquanto, é isso. Devo continuar me aprofundando em WCF e .NET 3.0 em geral e, qualquer descoberta interessante, vou postando por aqui :)

Feliz Ano Novo!

MoniqueLouise — Mon, 08 Jan 2007 05:58:00 GMT

Ainda que com um pouco de atraso (afinal, faz um certo tempo que eu não posto...), desejo a todos um feliz 2007! Esse ano que entra, pretendo me aprofundar em mais algumas tecnologias Microsoft (.NET 3.0, em especial WCF e WPF) e, sempre que possível, estarei postando descobertas técnicas e outras novidades!

Abraços a todos!

Monique

Gerenciamento de Projetos Ágeis

MoniqueLouise — Wed, 06 Dec 2006 03:48:00 GMT

Há quase dois meses tive a oportunidade de assistir a uma palestra sobre gerenciamento de projetos ágeis, com o Márcio Tierno, da Compuware. Um dos aspectos mais interessantes da metodologia diz respeito a estabelecer prazo e custo fixo, e ir priorizando as funcionalidades do projeto de acordo com as preferências do cliente. Ou seja, a cada nova interação (detalhe: cada interação deve durar no máximo 2 semanas), é gerado um release funcional, para que o próprio cliente possa avaliá-lo (e se for o caso, propor mudanças) e decidir quais são as features a serem entregues na próxima iteração. Obviamente, se houver mudanças, features de menor prioridade serão substituídas pelas mudanças. O que ocorre de fato é que a lista original de funcionalidades projetada no início do projeto dificilmente é implementada, uma vez que várias funcionalidades foram sendo substituídas à medida que o cliente ia amadurecendo o entendimento do escopo. Resultado: projeto entregue no prazo, no custo combuinado e com o escopo o mais próximo possível do desejado pelo cliente.

Web Services Enhancements 3.0

MoniqueLouise — Tue, 05 Dec 2006 10:35:00 GMT

Eu estava validando a arquitetura para uma prova de conceito que envolve o uso de Web Services utilizando um canal seguro de comunicação. Existem soluções antigas para esse problema, como a habilitação do uso de SSL na configuração do serviço no IIS, além de soluções in-house para criptografia de mensagens e passagem de tokens de autenticação (ex.: login/senha) no cabeçalho das mensagens SOAP. Essas soluções, apesar de funcionarem, apresentam algumas limitações:

- SSL é um protocolo que atua ponto a ponto, e não fim a fim. Isso significa que, havendo intermediários na comunicação cliente-servidor, a mensagem criptografada tem que ser descriptografada no intermediário, uma vez que uma nova seção SSL deve ser aberta a cada par de máquinas que se comuniquem. Essa nova seção exigirá uma nova criptografia da mensagem, todo um processo de handshaking, etc. Chamamos essa abordagem de "segurança a nível de transporte". Nela, a segurança é totalmente delegada para o sistema operacional, havendo aí uma dependência de plataforma (apesar de que várias plataformas hoje em dia suportam SSL)

- o uso de soluções in-house claramente apresenta problemas de interoperabilidade, uma vez que cada organização estará adicionando seus próprios headers, implementando suas próprias políticas "from scratch".

Para solucionar os problemas acima, foi definido um conjunto de padrões: WS-*. São vários padrões que se unem aos padrões já existentes para web services (SOAP, UDDI, etc.) para solucionar não apenas questões de segurança (autenticação, autorização, confidencialidade e integridade) mas também transações distribuídas, roteamento, envio de anexos binários, entre outros. O WS-Security trata especificamente da parte de segurança, e implementa a chamada "segurança a nível de mensagem", o que significa que mensagem XML original é criptografada, com a flexibilidade de apenas partes dela poderem ser criptografadas, e tokens de autenticação são automaticamente anexados e criptografados, de forma transparente para o desenvolvedor. Com isso não há nenhuma dependência em relação a plataforma.

A implementação MS para esses padrões é o Web Services Enhancements, ou WSE, que já está na sua versão 3.0. Esse não é um produto novo, mas só agora tive a oportunidade de avaliá-lo em um cenário real. O legal é que ele interopera com o Windows Communication Foundation.

A explicação abaixo está desatualizada em relação às maiores facilidades que o Windows Communication Foundation (WCF) fornece para segurança de Web Services, mas são úteis caso você precise rapidamente implementar segurança em seus web services e ainda não tiver um domínio a cerca das novas features do .NET 3.0, ou mesmo se não estiver planejando migrar código já existente para usar o WCF.

A título de exemplo da implementação de uma política de segurança para um web service, em geral são necessários poucos passos:

Após instalar o WSE 3.0, automaticamente o plug-in para o Visual Studio é instalado. Dessa forma, para habilitar o WSE em um web service, basta selecionar com o botão direito do mouse o projeto onde está o web service e clicar em WSE 3.0 Settings. A seguinte janela aparecerá:

Os check boxes exibidos devem ser marcados para que o WSE seja habilitado no projeto em questão.

Vamos passar agora à definição de uma política de segurança. Embora seja possível implementar políticas customizadas, o WSE já vem com um suporte pré-configurado a cenários comuns, a saber: autenticação com login/senha, certificado X.509, segurança integrada do Windows (autenticação via Kerberos), etc. Vamor ver, por exemplo, o passo-a-passo para definir uma política com autenticação baseada em login/senha, com criptografia e assinatura digital das mensagens trafegadas.

Na aba Security, escolha as opções "Enable Policy" e "Add" em "Edit Application Policy":

O wizard de definição de política entra em cena, após ser solicitado que se digite um nome para a política. Na primeira tela de configuração, é possível escolher se a política que está sendo definida é para um serviço ou para um cliente. No nosso exemplo, estamos configurando a segurança de um serviço. Ao mesmo tempo, podemos escolher o modo de autenticação desejado.

Também é possível definir já as políticas de autorização. Basicamente, nomes de papéis e usuários são gerados no arquivo de polítca que será criado ao fim da execução do wizard (embora essa não seja uma opção muito segura - o ideal é que a sua aplicação faça uso de uma base de usuários e papéis).

Um passo bem importante é a definição do nível de proteção que se deseja. Particularmente, quando estamos trabalhando com autenticação do tipo UsernameToken (login/senha), ao escolhermos a opção None, o WSE assume que a mensagem será protegida por SSL. Observação: o uso do SSL não é forçado pelo WSE. Nesse caso, você precisa configurar seu web service para usar a segurança a nível de transporte.

Finalmente, é solicitado que se especifique qual certificado será utilizado para a parte de criptografia e assinatura digital. Certificados digitais em geral contém duas chaves: uma pública, usada para criptografar a chave simétrica que será utilizada na criptografia e descriptografia das mensagens, e uma chave privada, conhecida apenas por aquele que receberá a mesagem, e que será responsável por descriptografar a chave simétrica. Essa é a base de funcionamento dos certiciados X.509, por exemplo. Essa é na realidade uma descrição auto-nível: a criptografia e assinatura digital de mensagens envolve um processo um pouco mais complicado de intercâmbio de chaves derivadas, quando utilizamos autenticação com login/senha. Chaves derivadas são, como o próprio nome diz, "derivadas" a partir da senha do cliente, e são elas as chaves simétricas a serem utilizadas nos mecanismos de criptografia e assinatura digital (no caso de assinaturas digitais, o hash da mensagem é que é criptografado).

Ao fim do processo, uma tela de confirmação é exibida com as opçoes que você escolheu, e o wizard pode ser finalizado. Para usar a política, base usar o atributo [Policy("nome da política")] na classe do web service, depois de adicionar a referência à DLL Microsoft.Web.Services3. Caso os seus clientes também estejam utilizando WSE, eles também em geral seguirão um processo análogo para a habilitação do WSE (quando um proxy WSE será gerado) e definição da política de segurança. Para usar a política, é só chamar SetPolicy("nome da política") no proxy. Adicionalmente, pode ser necessário chamar métodos para anexar tokens de autenticação, dependendo de como a política foi configurada. Todo esse processo está bem documentado nos manuais e demos que vêm com o WSE. No caso dos clientes, é necessário que eles adquiram previamente uma cópia da parte pública do certificado do servidor. O WSE não suporta a obtenção dinâmica do certificado, tal qual ocorre no SSL. Um detalhe importante: o WSE vem com certificados digitais de teste, cujas instruções de instalação são incluídas na própria documentação. Mas para que esses certificados possam ser usados, é necessário que a opção "Allow test roots" tanto no servidor como no cliente. Também é importante lembrar que esses certificados não devem ser usados em ambiente de produção, tanto por questões de segurança como de performance.

Antes de finalizar este post, uma dica: o guia que está disponível para download em http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp.

Treinamento gratuito em .NET 3.0

MoniqueLouise — Mon, 13 Nov 2006 18:10:00 GMT

Para que quiser conferir: https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=109340

Centro XML transforma-se em Centro de Inovação Microsoft

MoniqueLouise — Tue, 07 Nov 2006 16:05:00 GMT

Segue uma notícia importante sobre o Centro de Inovação MS Recife...

Fonte: http://www2.portodigital.org/portodigital/imprensa/ultimasnoticias/38966;42313;0805;1653;8463.asp

Centro XML transforma-se em Centro de Inovação Microsoft

Os Centros de Inovação Microsot foram criados em 2001 - na época, ainda sob a denominação "Centros de Tecnologia XML" - para atuarem como elo de integração entre as instituições educacionais, governo, mercado privado e empresas de desenvolvimento e integração de tecnologia, com o objetivo de acelerar a adoção das novas tecnologias Microsoft.

O Centro de Inovação Microsoft de Recife é a ramificação pernambucana desta iniciativa. Localizado noPorto Digital, ele conta com profissionais certificados e infra-estrutura composta de laboratórios, salas de reunião, salas de treinamento, servidores e estações de trabalho para atividades de capacitação profissional e transferência de tecnologia.

O Centro de Inovação Microsoft de Recife é um centro de excelência em Tecnologia Microsoft. Seu propósito é difundir tecnologias Microsoft, como a Plataforma .NET, e orientar empresas, instituições acadêmicas e desenvolvedores em geral na adoção e melhor utilização dessas tecnologias com:

      · Provas de Conceito (PoCs): projetos de software de menor escopo e duração, com média cinco semanas. O cliente, juntamente com o Centro de Inovação, define o problema a ser resolvido, que tipicamente consiste na validação de uma ou mais tecnologias Microsoft em um contexto específico. Uma semana para o treinamento desses colaboradores nas tecnologias a serem utilizadas também está incluida.
      · Adoption Labs: treinamento prático sobre a migração de certas plataformas para tecnologias Microsoft, como por exemplo, VB 6.0 para VB .NET, PHP para ASP.NET, Java para C#, Delphi para C#, Oracle para SQL 2005, etc.
      · Palestras e Workshops: eventos que visam promover a capacitação em tecnologias Microsoft.
      · Acordos de Cooperação: representam parcerias entre o Centro de Inovação com instituições acadêmicas ou ISVs (Independent Software Vendors). Através desses acordos, parceiros usufruem do apoio do Centro de Inovação Recife para a aplicação de tecnologias e ferramentas Microsoft a suas necessidades.

O Centro de Inovação Microsoft de Recife utiliza e incentiva o uso de metodologia Pro.NET, que reúne as melhores práticas de RUP, Microsoft Solutions Framework e metodologia ágeis, a exemplo do XP.

O Centro de Inovação Microsoft de Recife já desenvolveu projetos de prova de conceito com as seguintes instituições: Banco BGN, WHITec, Qualiti Software Processes, Centro de Informática - UFPE, MidiaVox, Ação Informática, WPD, CIEE, Inteligência Informática, ATI e Strive.

Centro de Inovação Microsoft de Recife.
Endereço: Rua do Apolo, 181, 1º. andar.
Fones: 81 34198137/8134.
Contato: Monique Monteiro - Gerente de Projetos.
E-mail: monique@qualiti.com.br

Nova família de certificações Microsoft

MoniqueLouise — Tue, 07 Nov 2006 08:36:00 GMT

Apesar de não ter havido a divulgação esperada, foi lançada em março deste ano a nova família de certificações Microsoft, que consiste basicamente em três níveis:

1- Microsoft Certified Technology Specialist: certificação voltada para tecnologias específicas

2- Microsoft Certified IT Professional OU Microsoft Certified Professional Developer: certifica o candidato em uma "profissão", ou seja, avalia um conjunto de habilidades. As duas certificações estão no mesmo nível: a primeira é mais pra quem tem perfil de infra, e a segunda para nós desenvolvedores. Exige como pré-requisito o Certified Technology Specialist e requer renovação periódica.

3- Microsoft Certified Architect: envolve um processo rigoroso de avaliação por parte de outros arquitetos, e em geral são exigidos 10 anos de experiência

Como a MS Certified Technology Specialist é obrigatória para quem quer seguir para os outros níveis, vamos a mais alguns detalhes sobre ela:

- Em primeiro lugar, vocês escolhe em qual tecnologia pretende se tornar especialista. As tecnologias disponíveis atualmente são:

.NET 2.0 Web Applications: Envolve 2 provas: Application Development Foundation, que visa a avaliar o seu conhecimento a respeito do framework .NET 2.0, APIs, etc. Vários aspectos como coleções, Generics, segurança, threads, interface gráfica, I/O, entre outros, são focados. A segunda prova é a Web-Based Client Development, que foca basicamente em desenvolvimento em ASP.NET (Web forms).

.NET 2.0 Windows Applications: Também exige 2 provas: Application Development Foundation, que já citei no item anterior, e a Windows-Based Client Development. Como o próprio nome dá a entender, é voltada pra quem pretende se especializar em Windows Forms.

.NET 2.0 Distributed Applications: Exige os exames Application Development Foundation e Distributed Application Development. Essa cerficação é bem interessante, pois envolve Web Services, Remoting, Enterprise Services e Message Queuing.

As outras certificações do nível MCTS são: SQL Server 2005, BizzTalk 2006, MS Office Live Communications Server 2005 e MS Windows Mobile 5.0 Applications. A boa notícia é que, para cada uma delas, basta fazer uma prova.

Os exames do nível Professional avaliam escolhas, decisões de projeto, de forma a focar mais na maturidade profissional em relação a tecnologias Microsoft. Para obter a certificação Professional, apenas um exame adicional é necessário, além do pré-requisito de ser MCTS. Na categoria Developer, mais uma vez existem três perfis:

Web Developer: tem como pré-requisito o MCTS em Web.

Windows Developer: tem como pré-requisito o MCTS em Windows.

Enterprise Developer: esse exigie que você seja MCTS em Web, Windows e Distributed Applications. Certamente é o caminho mais longo, mas também agrego muita conhecimento.

Maiores informações sobre o novo programa de certificações pode ser encontrado em: http://www.microsoft.com/learning/mcp/newgen/default.mspx

Primeiro post

MoniqueLouise — Tue, 07 Nov 2006 04:20:00 GMT

Olá,

criei este blog hoje para compartilhar com a comunidade descobertas, idéias e notícias sobre Engenharia de Software, .NET, Arquitetura de Soluções, Linguagens de Progrmaação/Compiladores e tecnologia em geral! Vamos às apresentações: trabalho no Centro de Inovação Microsoft Recife como Gerente de Projetos e Arquiteta de Software (nas horas vagas :), já que a equipe é pequena...). Terminei este ano o mestrado em Linguagens de Programação com foco na Plataforma .NET, em um projeto bem legal, que envolvia implementar a linguagem Haskell no .NET. Maiores detalhes em: www.cin.ufpe.br/~haskell/haskelldotnet.

Bem, para quem quiser me conhecer um pouco mais, eis minha página pessoal: www.cin.ufpe.br/~mlbm.

Até breve,

Monique