Igor Abade V. Leite (a.k.a "T-Shooter"): Blog

jQuery e Microsoft – Sinal dos tempos?

Mon, 29 Sep 2008 02:06:27 GMT

Este blog foi criado para falar exclusivamente sobre Visual Studio Team System. Hoje vou abrir uma pequena exceção.

Não é novidade para as pessoas que me conhecem quão apaixonado sou pelo produto – ter recebido o título de MVP foi essencialmente uma consequência dessa paixão.

Acho que é natural para qualquer pessoa apaixonada sempre querer o melhor para sua paixão. Neste caso, obviamente torço (e faço minha parte, claro!) para que o VSTS seja a melhor e mais utilizada solução de ALM do mundo.

Mas e o quê isso tem a ver com o título deste post? Bem, inúmeras vezes perguntamos ao time de produto porque investir seu limitado orçamento (acredite, o orçamento dos times de produto na Microsoft é limitado sim :)) desenvolvendo novas soluções quando existem excelentes alternativas no mundo open-source? Um exemplo bastante recorrente de discussão é NUnit vs. MSTest. Por quê a Microsoft criou um novo framework de testes unitários ao invés de usar o NUnit? Empresas como IBM e Oracle têm se beneficiado de um relacionamento mais estreito com projetos de código-aberto.

A resposta do time de produto faz sentido – até certo ponto. Mas antes de dizer qual a resposta do time de produto, sabe a pena refletirmos um pouco sobre como a comunidade de uma forma geral enxerga o relacionamento da Microsoft com projetos de código aberto. Muitas pessoas acreditam que a Microsoft é estritamente contra código aberto, que quer sufocar qualquer projeto que não saia de seus laboratórios… Bem, nada mais longe da verdade:

Antes de mais nada, deixemos de lado o romantismo tolo seguido por muitos dos defensores de projetos de código aberto. A Microsoft, como qualquer outra empresa neste nosso mundo capitalista, visa ao lucro. Ponto. Sendo assim, ela vai “combater” a concorrência aos seus produtos a fim de aumentar suas vendas. Nesse sentido, seus concorrentes são outros produtos similares aos que ela própria desenvolve – independentemente de serem open-source ou closed-source. Por isso, não faz sentido dizer que a Microsoft seja contra o modelo de desenvolvimentos de softwares em código aberto;
A própria Microsoft já liberou MUITOS projetos de código aberto que são consumidos livremente pela comunidade, abertos à contribuições, melhorias e sugestões vindas de desenvolvedores do mundo inteiro;
Apesar de já existirem sites que ofereciam hospedagem de projetos de código aberto (SourceForge é um dos mais conhecidos), havia espaço para um novo portal, capaz de oferecer o melhor em termos de controle de versão e rastreamento de itens de trabalho. Com o CodePlex a Microsoft mostrou que pode apoiar o desenvolvimento de qualquer projeto, usando qualquer licença de código aberto – “no strings attached”.

Porém, na minha opinião faltava um último passo da Microsoft no seu relacionamento com F/OSS: se libertar da “Síndrome do Não-Inventado-Aqui”. O tal do not-invented-here sempre impediu que a Microsoft usasse em seus produtos qualquer coisa que fosse desenvolvida por terceiros – principalmente código aberto. Agora podemos voltar aos motivos do time de produto para não usar o NUnit: do ponto de vista legal, sempre foi bastante nebuloso entender o que aconteceria do ponto de vista da Propriedade Intelectual se a Microsoft usasse código de terceiros. Na dúvida, ela sempre se limitou ao seu próprio código (o do invented-here).

Hoje vi um post do ScottGu que pode significar o começo da mudança. A Microsoft vai distribuir um projeto open-source – jQuery, um framework de programação JavaScript – como parte do ASP.NET MVC e do próprio Visual Studio!

Tomara que isso realmente signifique que a Microsoft possa, daqui para a frente, usar os excelentes projetos open-source que existem para criar produtos ainda melhores, contribuindo de volta para a comunidade as melhorias que vierem como parte dessa utilização.

Sinal de bons tempos por vir? Torço para isso.

CodePlex em destaque: Team Development with Team Foundation Server (tfsguide)

Fri, 29 Aug 2008 22:34:48 GMT

Como prometido, esta é a primeira edição do CodePlex em destaque – primeira de muitas, espero eu .

O projeto que gostaria de destacar hoje é o Team Development with Team Foundation Server – um projeto conjunto do time de Patterns & Practices da Microsoft e do time de produto do Team Foundation Server, além de alguns parceiros e especialistas do mercado.

A idéia do guia é consolidar um guia de “boas práticas” para utilização do TFS num ambiente de desemvolvimento. Leitura obrigatória para qualquer um quer pretenda usar o TFS!

Os tópicos abordados são:

Fundamentals
Source Control
Builds
Large Project Considerations
Project Management
Process Templates
Reporting
Setting Up and Maintaining the Team Environment
Visual Studio Team System 2008 Team Foundation Server

Technorati Tags: VSTS,TFS,Team System,CodePlex

CodePlex em destaque – Fique ligado!

Thu, 28 Aug 2008 13:31:30 GMT

Tem muita gente que nunca ouviu falar no CodePlex. Para quem não conhece, o CodePlex é um site que oferece a desenvolvedores de software livre (código aberto, open source) toda a infraestrutura para que possam hospedar seus projetos. Esses projetos podem ser desenvolvidos em qualquer tecnologia, para qualquer plataforma. A única exigência é que o software seja oferecido com algum tipo de licença de código aberto.

Esse site tem uma característica técnica bastante interessante: a estrutura de Gerência de Configuração (Controle de Versão e Gestão de Problemas) é baseada no Team Foundation Server. Ou seja, você pode usar o TFS de forma gratuita para hospedar seus projetos open-source. Você pode inclusive baixar o Team Explorer (também gratuito) para integrar seu Visual Studio (Standard ou superior) ao CodePlex.

Se o próprio site é desconhecido, o que dizer dos projetos hospedados lá? Há muita coisa bacana, bastante útil, e que poderia ajudá-lo a resolver problemas que você possa ter no seu dia-a-dia. Por isso, resolvi criar uma categoria especial (e recorrente) de postagens: CodePlex em destaque.

Toda sexta-feira irei destacar algum projeto hospedado no Codeplex e que esteja de alguma forma ligado ao Visual Studio Team System. Amanhã teremos o primeiro post da série.

Aguarde!

Technorati Tags: VSTS,Team System,TFS,CodePlex

Como desfazer check-outs de outros usuários

Thu, 21 Aug 2008 14:02:46 GMT

Quantas vezes já passamos (ou vimos alguém passar) por isso?

“Um funcionário saiu da empresa e largou um monte de arquivos em check-out. Ninguém sabe a senha dele. Mas nem ia adiantar, a máquina já foi formatada mesmo…”

E agora, como cancelar os check-outs feitos por outro usuário? O segredo está na (relativamente pouco conhecida) ferramenta de linha de comando do Team Explorer, tf.exe. Abra o prompt de comando do Visual Studio 2008 e execute:

tf workspaces /owner:<nome_do_usuário> /server:<nome_do_servidor>

Com isso você consegue listar os workspaces do usuário em questão. Você vai precisar dessa informação para a próxima etapa:

tf undo /workspace:<nome_do_workspace>;<nome_do_usuario> /recursive /server:<nome_do_servidor> $/*.*

Para cada workspace listado na etapa anterior, execute o comando acima.

Technorati Tags: VSTS,TFS,Team System

Service Packs e Power Tools

Fri, 15 Aug 2008 14:15:10 GMT

Com o recente lançamento do Service Pack 1 do Visual Studio 2008 e Team Foundation Server 2008, muitas coisas são atualizadas em seu computador:

Visual Studio 2008 SP1

Visual Studio (todas as edições)
.NET Framework 3.5

Team Foundation Server SP1

Team Foundation Server (AT)
.NET Framework 3.5

Mas há algumas ferramentas que, de tão naturais no nosso dia-a-dia, que acabam se tornando “invisíveis”. Esquecemos que elas são downloads adicionais e que não fazem parte do produto original.

Esse é o caso com o pacote “Team Foundation Server Power Tools”. São ferramentas extremamente úteis e que complementam o Visual Studio e o TFS.

Dentre todos os componentes do pacote Power Tools, provavelmente o mais conhecido é o Team System Web Access.

Porém, muitos acreditam que o TSWA é parte integrante do Team Foundation Server – e que, com isso, ele será atualizado automaticamente durante a instalação do Service Pack do TFS. Bom, na verdade o SP1 não atualiza o TSWA. Ele deve ser atualizado à parte, como todo o restante do pacote Power Tools. Devemos ter, em breve, o lançamento da versão “correnpondente ao SP1” do TSWA.

No futuro, o Rosario trará mudanças nesse aspecto. O Team System Web Access finalmente passará a ser parte integrante do produto e, por isso, será atualizado junto com quaisquer service packs que venham a ser criados.

Technorati Tags: VSTS,TFS,Team System,TSWA,Team System Web Access,SP1

“No nosso projeto, estamos sempre 90% prontos”

Sat, 09 Aug 2008 00:05:43 GMT

Recentemente, o Jeff Atwood (“Coding Horror”) escreveu um post com o título acima. Vale a pena dar uma liad no post inteiro; por enquanto, veja o trecho abaixo que extraí – foi o que mais me chamou a atenção:

Johanna Rothman makes the same point in a recent email newsletter, and offers specific actions you can take to avoid being stuck 90% done:

List everything you need to do to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.
Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.
Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.
Determine a way to show visible status to anyone who's interested. If you're the person doing the work, what would you have to do to show your status to your manager? If you're the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.
Since you've got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking. (See the article about the Split Focus schedule game.)

I'm not big on scheduling -- or lists -- but without the latter, I cannot have the former. It's like trying to defy the law of gravity. Thus, on our project, we're always 90% done. If you'd like escape the 90% done ghetto on your software project, don't learn this the hard way, like I did. Every time someone asks you what your schedule is, you should be able to point to a list of everything you need to do. And if you can't -- the first item on your task list should be to create that list.
On Our Project, We're Always 90% Done

Sabe o que mais me chamou a atenção no trecho acima? É que quando visito cliente para falar de Team Foundation Server e explico como usar work items para a gestão de projetos, é exatamente desse jeito que eu sugiro usar o TFS!

Se você seguir essas dicas como um princípio de boas práticas no uso de work items (independentemente do processo de desenvolvimento que esteja usando) sua experiência será muito mais rica.

Relacione tudo o que você tem que fazer (“List everything you need to do to finish the big chunk of work”)

Aqui o Excel é seu aliado. Use-o para relacionar rapidamente todas as atividades-macro que você já identificou durante a fase de levantamente/especificação/planejamento (ou como chamar no seu processo de desenvolvimento). Aproveite para dividir as atividades por área e/ou iteração.

Estime cada item na lista (“Estimate each item on that list”)

Use o Excel ou o Project (para muitos, o Project é o preferido nesse tipo de atividade). Faça uma estimativa inicial do tempo que se levaria para executar cada uma das atividades identificadas no processo anterior. Não se preocupe em ser preciso; você vai refinar essas estimativas depois.

Divida suas atividades em pedaços de no máximo 8 horas (“If you have a task longer than one day, break that task into smaller pieces”)

Na minha opinião, este é o ponto-chave para um uso bem-sucedido do TFS. Se você fizer um bom WBS (work breakdown structure), chegando um nível de detalhamento que garanta que suas atividades terão no máximo 8 horas, terá conseguido algo muito difícil: o comprometimento da equipe de desenvolvedores com a prática de relatório de status (status report).

O “pulo-do-gato” é que nenhum desenvolvedor seria obrigado a fazer nada além daquilo que ele faz normalmente: o check-in do código que acabou de produzir. Ao dividir as atividades em unidade de até oito horas, você praticamente garante que seus desenvolvedores:

Farão check-in apenas de código completo (afinal, eles terminam a atividade no mesmo dia em que começaram);
Farão check-in ao menos uma vez por dia (pelo mesmo motivo do item 1).

Alie-se a isso a política de check-in de work items e você terá feedback diário das atividades dos seus desenvolvedores – tudo o que eles precisam fazer é clicar uma checkbox na caixa de diálogo de check-in. “Magicamente” seus relatórios começarão a ter dados para os alimentar.

Divulgue o status do seu projeto (“Determine a way to show visible status to anyone who's interested”)

Quer ferramenta melhor que o Portal do Projeto do TFS, feito em SharePoint, para isso? Crie seus painéis de controle (“dashboards”) para que os interessados possam acompanhar o andamento do projeto.

Acompanhe o progresso do projeto diariamente (“Track your progress daily”)

Além do Excel, Project ou mesmo os relatórios disponíveis no Portal do Projeto, você pode usar também as inúmeras consultas de work items do TFS (e até mesmo criar suas próprias) para acompanhar seu projeto.

Viu? Com alguns cuidados básicos (e com um esforço relativamente pequeno) você consegue tirar proveito facilmente dos recursos de gestão de projetos do TFS!

Technorati Tags: VSTS,TFS,Team System,Project Management,Work Items

SQL Server 2008: Alive and kicking!

Wed, 06 Aug 2008 19:31:27 GMT

Boas notícias! O SQL Server 2008 já está disponível para download para assinantes MSDN e Technet.

“Legal. E o que isso tem a ver com o Team System?”

Que bom que você perguntou… :-)

O Service Pack 1 do Visual Studio 2008 (às vésperas de ser lançado) oferece suporte nativo ao SQL Server 2008. Com isso:

Será possível usar o SQL Server 2008 como back-end do TFS (hoje você precisa usar o SQL 2005);
O VSTS Database Edition reconhecerá a nova versão do SQL, para que possamos fazer controle de versão, testes unitários de bancos de dados, comparação de schema etc.

Technorati Tags: VSTS,TFS,Team System,Database Edition,DataDude,SQL Server,SQL Server 2008,VS SP1

Por que as políticas de check-in não são obrigatórias?

Wed, 06 Aug 2008 17:26:32 GMT

Mais uma da série “dúvidas comuns que respondemos infinitas vezes”: Por que as políticas de check-in não são obrigatórias?

O recurso de check-in policy (política de check-in) é percebido pelos usuários do TFS como uma grande vantagem. Com ele, é possivel definir algumas premissas para a aceitação do código-fonte:

Você testou seu código antes de fazer check-in?
Você analisou o seu código para garantir que ele atende aos padrões da empresa?
Você lembrou de associar suas alterações no código à atividade/demanda que originou essas alterações?

As políticas de check-in são definidas em nível de projeto (Team Project) e se aplicam a todos os desenvolvedores que atuam no tal projeto. Toda vez que eles tentam efetuar um check-in, as políticas são validadas e o usuário é alertado caso elas não sejam atendidas.

O ponto mais polêmico em relação às políticas de check-in é que elas podem ser ignoradas pelo usuário!

Por quê isso? Já ouvi pessoas falando que a Microsoft fez o serviço “pela metade”, deixando de fora a possibilidade de barrar o check-in. Bom, temos algumas explicações para isso. A primeira delas vem de um blog de FAQ do Team System:

Can we disable the “Override CheckIn Policy Failure” checkbox? Can that be customized based on User Login, Policy Type or File type?
No. We get a lot of requests for this but our contention is that the person defining the policy can’t envision the situations that will arise where policy will need to be overridden. Thus, we designed it to be fully auditable by including policy compliance data in the changeset details and in the checkin mail that is delivered, but left it up to the developer to determine whether they have a good reason for overriding.

A razão é simples: se o desenvolvedor optou por ignorar a política de check-in, ele deve ter um bom motivo. Trabalho em equipe presume confiança entre seus membros, logo não faz sentido partir da premissa que todos são imaturos e irresponsáveis. Entretanto, como auditoria é fundamental em qualquer projeto (mesmo nos “ágeis”), o TFS registra no evento de check-in sempre que alguém optou por desconsiderar políticas de check-in que não estavam sendo atendidas.

Dica: Na edição de Julho/2008 do Team Foundation Server Power Tools há uma nova ferramenta, o Alert Editor, que simplifica bastante o processo de auditoria das políticas de check-in. Adicione um alerta para ser notificado sempre que alguém optar por ignorar uma política definida num team project:

Entendendo políticas de check-in - com sorte, de uma vez por todas :-)

Há uma triste verdade a respeito das políticas de check-in, uma ainda pior que o fato de podermos usar o famigerado “override”: políticas de check-in não são universais. Ou seja, elas não são executadas e garantidas pelo servidor. Cada aplicativo-cliente é responsável por executar as políticas de check-in que lhe convierem.

Do ponto de vista técnico, check-in policies nada mais são que assemblies .NET instalados em cada computador onde serão executados. Esses assemblies contêm algumas classes que implementam interfaces específicas definidas no SDK do Visual Studio. Quando instalamos o Team Explorer (cliente do TFS), recebemos “de brinde” as quatro políticas de check-in originais.

No ato do check-in, o programa que o desenvolvedor estiver usando (por exemplo, o Visual Studio 2008) contata o servidor e obtém uma lista com os nomes das políticas de check-in que deveriam ser executadas, junto com suas respectivas configurações (que também foram definidas no servidor). Em seguida, verifica se essas políticas estão disponíveis no computador local e procede à sua execução. Com isso, podemos entender a afirmação de que “cada aplicativo-cliente é responsável por executar as políticas de check-in que lhe convierem”.

O Visual Studio (2005/2008) é o cliente “premium” para o TFS. Como tal, é o único que garante executar todas as políticas de check-in que estiverem devidamente registradas no servidor e instaladas no computador do desenvolvedor. Isso traz uma variável adicional ao já conturbado universo das check-in policies. Ainda que possamos criar nossas próprias políticas de check-in (acrescentando novas opções às quatro originais), não há nada que garanta que elas serão executadas. Isso me faz lembrar de um velho problema que aflite desenvolvedores Web há muito tempo: Validação no Cliente vs. Validação no Servidor.

Validação no Cliente vs. Validação no Servidor

No universo da Web, aplicativos feitos em qualquer tecnologia (ASP.NET, PHP, Ruby, Java etc…) certamente se vêem às voltas com a necessidade de solicitar dados ao usuário. Formulários são usados para as mais diferentes entradas de dados. Porém, o HTML não é exatamente a melhor tecnologia para a criação de formulários de dados. Ele não tem praticamente nenhum recurso padrão de validação de conteúdo que os browsers possam usar para conferir o que o usuário nos levou. Isso geralmente leva a duas opções:

	Prós	Contras
Validação no Cliente	Rápido. Feedback instantâneo ao usuário. Dados incorretos podem ser facilmente corrigidos, sem a necessidade de uma “viagem de ida e volta” dos dados ao servidor para a validação	Inseguro. Como depende de Javascript, pode não ser executado (ex.: o usuário desativou a execução de scripts em seu browser). Além disso, o usuário poderia, maliciosamente ou não, subverter o script, fazendo-o aceitar dados inválidos.
Validação no Servidor	Seguro. O código rodando dentro do servidor está fora do alcance de usuários maliciosos, que não poderão alterar as regras de validação. Não há como forçar a entrada de dados inválidos.	Lento. Os dados precisam ser enviados ao servidor para que possam ser validados. Se forem encontrados erros nas informações prestadas pelo usuário, é necessário enviar uma notificação ao browser para que seja feita a correção – depois da qual o processo recomeça.

As boas práticas do desenvolvimento para a Web nos dizem que devemos, sempre que possível, oferecer as duas opções ao mesmo tempo. A conveniência da validação no cliente aliada à segurança da validação no servidor. Repare que a validação no cliente tem apenas o papel da conveniência, nunca podendo substituir a validação no servidor. Se tiver que optar por apenas uma delas, não há dúvidas: fique com o servidor.

Bom, você deve estar se perguntando, mas o que isso tem a ver com o assunto em pauta? Tudo! Encare as políticas de check-in do TFS como client-side validation: rápidas, porém inseguras. Se eu realmente quiser garantir que o check-in é seguro e atende às definições do meu processo de desenvolvimento, preciso ter o equivalente TFS da server-side validation. As alternativas são:

Team Build + Integração Continua (CI, Continuous Integration): Com o TFS 2008 é possível disparar o processo de build automatizado do Team Build simplesmente fazendo um check-in. Com isso, podemos verificar se as alterações que acabaram de ser produzidas se integram adequadamente ao restante do código já existente no repositório. Efetuar o build a cada check-in visa a validar continuamente a integração entre os diversos trechos de código produzidos todo o tempo pela equipe de desenvolvimento. Daí vem o termo integração contínua. Como o processo de build é disparado automaticamente pelo ato de check-in, e como ele ocorre no agente de build (e não na máquina do desenvolvedor), ele acaba sendo o equivalente da validação de servidor das aplicações Web. Podemos rodar a análise estática de código, podemos rodar testes unitários, podemos auditar o código. Se houver algum problema, o build é marcado como falho (“quebrado”). O changeset (as alterações feitas pelo desenvolvedor) que deu origem ao build pode, então, ser desfeito (usando, por exemplo, o comando tfpt rollback).
Gated check-in: O problema da solução apresentada acima, baseada apenas no servidor de build, é que o check-in precisa ser feito antes de ser validado. Ou seja, em caso de problemas eu necessariamente terei que desfazer manualmente as alterações que quebraram o build. O ideal seria que eu pudesse disparar o buid antes do check-in, só efetivando a alteração no controle de versão se tudo corresse bem. É justamente disso que trata o conceito de gated check-in: As operações de check-in são interceptadas (geralmente usando shelvesets) e redirecionadas para um servidor de build especial. Esse servidor combina o código-fonte que já existe no TFS com as alterações que acabaram de vir do desenvolvedor. Se tudo correr bem, só então é que o check-in será consumado. O TFS “Rosario” terá suporte nativo a gated check-in. Por enquanto, você pode usar o OpenGauntlet para ter esse recurso à disposição no TFS 2008.

Resumo da ópera

Politícas de check-in são um recurso bastante poderoso e conveniente. Devido ao fato de poderem ser facilmente burlados, devem ser usados apenas como lembrete para os desenvolvedores. Dessa forma, eles serão lembrados de testar seu código, associar work items etc. Para garantir que o código produzido por sua equipe atenda aos critérios definidos em sua empresa, utilize alguma técnica de gated check-in.

Technorati Tags: TFS,VSTS,Team System,Check-in Policy

Por falar em testes de carga – WCF Load Test

Tue, 15 Jul 2008 21:32:03 GMT

No último post mencionei uma nova ferramenta dos VSTS Rangers para a criação de testes de carga para o SQL Server. Agora vale a menção de um projeto mais antigo dos mesmos Rangers, só que para o teste de carga de serviços WCF.

O WCF Load Test é uma ferramenta que converte um trace WCF em um teste unitário que pode ser usado como parte de um teste de carga. Combinado com os testes de carga Web e os para o SQL Server, você consegue criar as condições necessárias para testar sua aplicação o mais próximo possível da realidade, confirmando que ela efetivamente suporta a quantidade de usuários que você espera.

Technorati Tags: VSTS,Team System,Load Test

Teste de carga de servidores SQL Server

Tue, 15 Jul 2008 09:29:54 GMT

O time VSTS Rangers (uma equipe dentro da Microsoft responsável por eliminar “entraves” na adoção do VSTS pelos clientes) acaba de lançar mais um projeto no CodePlex: é o SQL Load Test.

A proposta é bem simples: a ferramenta de teste de carga que faz parte do Visual Studio Team System é realmente incrível, porém oferece suporte nativo apenas a aplicações Web. Como fazer um teste de carga para, por exemplo, um aplicativo cliente/servidor desenvolvido em WPF ou Windows Forms? Tipicamente o que importa num teste de carga num cenário como esse é avaliar a performance do servidor de banco de dados. Para tanto, basta iniciar a gravação de um arquivo de trace do SQL Server e utilizar normalmente a aplicação, registrando sua interação com o servidor;

A partir desse arquivo de trace do SQL Server, é possível criar um teste unitário que contém as chamadas ADO.NET correspondentes ao conteúdo do arquivo de trace. Com isso, é possível criar um teste de carga que execute esse teste unitário para efetivamente estressar o servidor.

Technorati Tags: VSTS,Team System,Load Test

Mais um grande blog de VSTS em português

Mon, 30 Jun 2008 22:51:00 GMT

O Ramon Durães, MVP de ASP.NET, tem postado muito conteúdo bacana de VSTS. Confira o seu site em http://blogs.2pc.com.br/ramonduraes/.

Dica: Dê uma olhada no post Controlando o tempo gasto em projetos de software - essa é uma dúvida bastante comum, sobre timesheeting no TFS.

Crie novas ferramentas para o Visual Studio e o TFS com o Visual Studio SDK

Wed, 18 Jun 2008 23:48:27 GMT

Poucas pessoas sabem, mas o Visual Studio tem um SDK (Software Development Kit) próprio. Com ele, é possível estender os recursos do Visual Studio (e também do TFS), com a criação de inúmeros componentes, tais como:

Add-ins e plug-ins para o IDE;
Políticas de check-in;
Linguagens de programação (isso mesmo! você pode criar sua própria linguagem de programação e hospedá-la no Visual Studio!);
Interação com work items;
E muito mais!

O SDK oferece um navegador muito bacana, no qual é possível encontrar inúmeros exemplos de como utilizar os componentes e bibliotecas oferecidos:

Além de permitir a criação de extensões para o IDE do Visual Studio e para o TFS, o VS SDK é usado para criar as soluções customizadas para o Visual Studio Shell.

Para saber mais sobre o SDK (e a extensibilidade da plataforma Visual Studio), consulte:

Technorati Marcas: VSTS,Team System,TFS,Visual Studio,Extensibility,VSX,SDK

Microsoft Dynamics AX e Team Foundation Server

Wed, 18 Jun 2008 23:36:08 GMT

Brian Harry acabou de anunciar: o recém-lançado Dynamics AX 2009 agora oferece integração com o controle de versão do TFS!

Less than a month ago, Dynamics AX 2009 was released. This new version enables Dynamics developers to store their source code and have an integrated experience for checkout, check in, get and history - the basic version control operations in TFS. I'm excited about this because I get the question fairly often and people are always surprised when I tell them we don't have a solution. Now I don't have to disappoint any longer.

Para saber como configurar o AX para armazenar o código-fonte no TFS, veja a documentação disponível em http://www.microsoft.com/downloads/details.aspx?FamilyId=EFC24EDC-522E-40AA-8F36-6367ED7AB92D&displaylang=en.

Technorati Marcas: VSTS,Team System,TFS,Dynamics AX

O que há de novo no Visual Studio Team System 2008?

Wed, 18 Jun 2008 03:21:58 GMT

Apesar de o VSTS 2008 já ter sido lançado há um tempo razoável - novembro do ano passado - ainda há muita gente que não sabe o que mudou desde a versão 2005. Por isso, resolvi fazer um resumo das alterações numa série de posts. Irei publicar os links aos poucos, conforme criar os posts.

Veja abaixo os links com os posts resumindo as mudanças da nova versão do Team System. IMPORTANTE: Aqui você encontra apenas os recursos específicos do Team System (TFS e Team Editions).

O que há de novo no Team Foundation Server 2008?
O que há de novo no Team Build 2008?
O que há de novo no VSTS Architecture Edition 2008?
O que há de novo no VSTS Development Edition 2008?
O que há de novo no VSTS Test Edition 2008?
O que há de novo no VSTS Database Edition 2008?

Para saber mais sobre as mudanças no Visual Studio e no .NET Framework:

O que há de novo no Visual Studio 2008?
http://msdn2.microsoft.com/en-us/library/bb386063.aspx
O que há de novo no .NET Framework 3.5?
http://msdn.microsoft.com/en-us/library/bb332048.aspx

Technorati Marcas: VSTS,Team System,Visual Studio,.NET

TFS também ama o Java (e o Delphi, e o PowerBuilder…)

Wed, 18 Jun 2008 02:56:07 GMT

O Team Foundation ainda é alvo de muito preconceito da comunidade de desenvolvedores. Só porque o nome do produto é “Microsoft Visual Studio Team System Team Foundation Server” (pequeno, né?) a maioria presume que TFS = .NET, já que assumem que Visual Studio = .NET. Bem, nada mais equivocado.

O ponto importante a se lembrar aqui é: O Visual Studio Team System é uma plataforma de ALM. ALM, ou Application Lifecycle Management, refere-se às práticas envolvidas na gestão do ciclo de vida de uma aplicação – desde a sua concepção, especificação e planejamento até a efetiva implantação no ambiente de produção. Repare que em nenhum lugar estava escrito “.NET Application Lifecycle Management”. Assim, ainda que obviamente a plataforma tenha recursos específicos para .NET (capazes de aumentar a qualidade e eficiência do trabalho da equipe de desenvolvimento), eu realmente acredito que nossa plataforma brilha nos cenários em que há vários ambientes (e linguagens) de desenvolvimento envolvidos.

Na sua empresa há um ambiente heterogêneo de programação? Há grandes chances que a resposta seja “sim”. Na maioria dos clientes que tenho visitado o mais comum é termos algo como “VB6 + .NET”, ou “Java + .NET”, ou “Delphi + VB + Java”, ou qualquer outra combinação que você imaginar. Como se não bastasse o fato de ter que lidar com múltiplas linguagens de programação, esses clientes normalmente acabam lidando com várias ferramentas usadas ao mesmo tempo no apoio à ALM: VSS, CVS, Subversion, Jira, Trac, Project Server, Primavera etc…

Quem já não viu esse cenário? “Projetos Java no Subversion, projetos VB no SourceSafe”. Como conseguir gerenciar isso de forma efetiva?

A resposta é clara: Use o Team Foundation Server para todos os projetos, independentemente da linguagem!

Eclipse

Veja o caso do Eclipse, um dos IDEs mais utilizados no desenvolvimento de aplicações Java (usando o plugin Teamprise). Com ele, você tem acesso total aos recursos do TFS – controle de versão, rastreamento de itens de trabalho, relatórios e documentos:

MSSCCI Provider

Há vários IDEs que ainda não oferecem suporte nativo ao TFS. Porém, se eles tiverem suporte ao Visual SourceSafe, há grandes chances de usar o TFS no lugar do VSS. Basta que eles se conectem ao VSS através de uma API chamada MSSCCI (Microsoft Source Code Control Interface). Com o Visual Studio Team Foundation Server MSSCCI Provider é possível “enganar” seu IDE, de modo que ele “fale” com o TFS pensando que é o SourceSafe. Alguns dos IDEs que utilizam essa API e que foram testados pela Microsoft para usar o MSSCCI Provider são:

Visual Studio .NET 2003
Visual C++ 6 SP6
Visual Visual Basic 6 SP6
Visual FoxPro 9 SP1
Microsoft Access 2003 SP2
SQL Server Management Studio
Sparx Systems Enterprise Architect 6.1
Sybase PowerBuilder 10.5
Toad for SQL Server 2.0

Para saber mais, há um artigo (já um tanto antigo, mas ainda válido) sobre o assunto em http://www.microsoft.com/brasil/msdn/tecnologias/vs2005/tfs.mspx.

Technorati Marcas: VSTS,Team System,.NET,Eclipse,Delphi,MSSCCI

Concurso: Qual o "gadget" mais legal para o Team System?

Mon, 16 Jun 2008 01:49:09 GMT

Você já desenvolveu alguma ferramenta para estender a funcionalidade do Team System? Conhece alguém que criou um programinha tão legal que mudou seu jeito de usar a solução de ALM da Microsoft? Que tal participar de um concurso para eleger o gadget mais legal para o Team System?

Mike Azocar, MVP de Team System, propôs o concurso Coolest Team System Gadget Contest. Do blog do Mike:

Have you created a useful gadget for Team System? Do you have one in mind? I am looking for the coolest community built tool for VSTS. It can be something for TFS, for Visual Studio, or something that is stand alone. The winner will receive a one year subscription to MSDN with Team Suite and a one year subscription to Infragistics NetAdvantage controls!
To enter, submit a screen cast (up to 3 minutes long) which tells everyone why your gadget is the coolest and the source code. All submissions will be released to the public as free source to use and enjoy (with you getting all the credit of course). Videos will also be made available to the public to help make you famous! This should be something new (i.e. not on Codeplex or previously released) and not something repackaged.

Inscreva-se até o dia 31/agosto. O vencedor será anunciado no dia 15/setembro. Inscreva-se! Vote no seu preferido!

Preciso instalar o Visual Studio no meu servidor de build?

Wed, 11 Jun 2008 04:52:13 GMT

Mais uma da série "dúvidas comuns sobre o Team System": Muitos clientes nos perguntam se é preciso instalar alguma versão do Visual Studio Team System no servidor de build (mais precisamente no agente de build - essa é a nomenclatura correta).

A resposta curta é: Provavelmente. A resposta completa é:

Se você pretende usar em seus builds algum dos recursos a seguir:

Testes em geral (unitários, web, carga etc.);
Análise Estática de Código (Code Analysis);
Testes Unitários de Banco de Dados;
Compilação e Implantação de Projetos de Banco de Dados.

Então você precisará instalar a versão adequada do Visual Studio no agente de build. Isso se deve ao fato de que os recursos listados acima são exclusivo do IDE, sendo "aproveitados" pelo agente no ato da execução do build. As DLLs que executam cada uma das funções acima não podem ser instaladas individualmente; para isso você deve instalar o Visual Studio, de acordo com a tabela abaixo:

Recurso	Versão Necessária
Testes Unitários	Team Developer ou Team Tester (2005); Professional (2008)
Testes em geral	Test Edition
Análise Estática de Código	Development Edition
Testes Unitários de Banco de Dados	Database Edition
Projetos de Banco de Dados	Database Edition

Para simplificar o processo de seleção listado na tabela acima, muitos de nossos clientes preferem instalar o Team Suite nos agentes de build.

Licenciamento

Este é um ponto muito importante: Na maioria dos casos, você NÃO PRECISA COMPRAR uma licença adicional para seus agentes de build. O licenciamento segue a seguinte lógica:

"A pessoa que criar o script de build pode instalar no agente de build a mesma licença que ela tem para uso em seu próprio computador"

Em outras palavras: Se eu tiver um Visual Studio Team System Development Edition (que eu uso no dia-a-dia para desenvolvimento dos meus sistemas) e for o responsável por criar o script de build, isso me dá o direito a:

Adicionar o recurso de Análise de Código (que faz parte do Development Edition) ao meu script de build;
Instalar o Visual Studio Team System Development Edition (que é a licença que eu tenho em meu próprio computador) no servidor de build, sem custo adicional.

Por isso, se você quiser usar num mesmo script de build os recursos de análise de código (Development Edition), testes (Test Edition) e banco de dados (Database Edition), a pessoa que cria o script de build deve ter o Team Suite.

Cobertura de Código - Só para testes unitários?

Wed, 11 Jun 2008 04:51:05 GMT

Antes de discutir cobertura de código, uma rápida recapitulação:

Cobertura de código: Uma métrica que indica a efetividade dos testes feitos em uma aplicação. Expressa em termos de porcentagem do código-fonte da aplicação, mostra extaamente o quanto da aplicação foi testada durante uma dada bateria de testes;
Testes Unitários: Pequenas rotinas (tipicamente escritas na mesma linguagem de programação do sistema que será testado) que descrevem regras de negócios e outros comportamentos conhecidos e esperados do sistema. Os testes unitários invocam rotinas e outras pequenas porções de código do sistema-alvo, suprindo parâmetros com valores pré-definidos e analisando o comportamento resultante, que deve estar de acordo com a regra de negócio ou comportamento esperado em questão.

Para que os testes unitários sejam efetivos, eles devem cobrir o maior número possível de "caminhos" no código da aplicação. A cobertura de código visa a responder justamente o quanto desses caminhos foi realmente testado. Veja um exemplo (totalmente fictício, hein?!) que ilustra tudo isso:

Regra de Negócio:

Para o cálculo do salário líquido de um funcionário, dados:

O valor do salário bruto;
Um "flag" indicando a adesão ao plano de saúde;
Um "flag" indicando a adesão ao vale-refeição;

Deve ser efetuado o seguinte cálculo:

Descontar o imposto de renda de acordo com com as seguintes faixas:
1. R$0 - R$1000: Isento;
2. R$1001 - R$2000: 5%;
3. R$2001 - R$3000: 15%;
4. R$3001 em diante: 25.
Descontar 10% de INSS;
10% do salário bruto, caso tenha aderido ao plano de saúde;
5% do salário bruto, caso tenha aderido ao vale-refeição.

Código-fonte da aplicação:

   1:  public class Empregado
   2:  {
   3:      public static double CalcularSalario(double salarioBruto, bool temPlanoSaude, bool temValeRefeicao)
   4:      {
   5:          var salarioLiquido = salarioBruto;
   6:   
   7:          // Cálculo do imposto de renda
   8:   
   9:          if (salarioBruto > 1000 && salarioLiquido <= 2000)
  10:          {
  11:              salarioLiquido -= (salarioBruto * .05);
  12:          }
  13:          else if (salarioBruto > 2000 && salarioBruto <= 3000)
  14:          {
  15:              salarioLiquido -= (salarioBruto * .15);
  16:          }
  17:          else if (salarioBruto > 3000)
  18:          {
  19:              salarioLiquido -= (salarioBruto * .25);
  20:          }
  21:   
  22:          // Cálculo do plano de saúde
  23:   
  24:          if (temPlanoSaude)
  25:          {
  26:              salarioLiquido -= (salarioBruto * .10);
  27:          }
  28:   
  29:          // Cálculo do vale-refeição
  30:   
  31:          if (temValeRefeicao)
  32:          {
  33:              salarioLiquido -= (salarioBruto * .05);
  34:          }
  35:   
  36:          return salarioLiquido;
  37:      }
  38:  }

Teste Unitário:

public void CalcularSalarioTest()
{
    // "Valores conhecidos". São arbitrários; posso usar qualquer valor

    double salarioBruto = 1500; 
    bool temPlanoSaude = false; 
    bool temValeRefeicao = true; 

    // "Valor esperado". Deve estar de acordo com a regra de negócio e com
    // os valores dados acima

    double expected = 1350; 

    // "Valor real". É o valor que será retornado pela minha rotina de cálculo;
    // se tudo der certo, deve ser igual ao "valor esperado"

    double actual;

    // Executa a rotina passando os valores acima como parâmetros

    actual = Empregado.CalcularSalario(salarioBruto, temPlanoSaude, temValeRefeicao);

    // Confere se os resultados ("valor esperado", "valor real") são iguais; se forem,
    // o teste é considerado bem-sucedido

    Assert.AreEqual(expected, actual);
}

Compare a regra de negócio, o código-fonte da aplicação e o teste unitário:

A rotina de cálculo está atendendo a todas as premissas da regra de negócio? No exemplo acima, sim.
O teste unitário está testando todas as variações possíveis da rotina de cálculo? No exemplo acima, não está:
- Não foram feitos testes para todas as faixas de salários (para garantir que o IRPF está sendo calculado corretamente);
- Não foram testadas outras variações para "plano de saúde" e "vale-refeição".

É justamente nesse momento que entra a cobertura de código. Ela nos ajuda a identificar quais pontos da rotina não foram testados:

Viu? A cobertura de código é quase indispensável quando estamos trabalhando com testes unitários. Ela nos dá a medida da eficácia do teste que escrevemos e acabamos de executar. Daí vem uma dúvida bastante comum quando discutimos cobertura de código e testes unitários no Team System. Tipicamente esses dois recursos são mostrados em conjunto - e por isso há quem acredite que são parte da mesma funcionalidade, e que portanto cobertura de código significa "porcentagem do código testado pelos testes unitários", quando na verdade significa "porcentagem do código testado"!

Cobertura de Código e outros testes

Veja como a cobertura de código se comporta em conjunto com alguns dos outros testes disponíveis no Team System. Para isso, crie uma solução com dois projetos: uma Web Application e um Test Project. Não se esqueça de ativar a cobertura de código para seu projeto Web Application (Test | Edit Test Run Configurations | Local Test Run):

Testes Manuais

Faça uma experiência: adicione um teste manual e execute-o. Enquanto ele estiver em execução, abra o seu web site (que deve ter sido carregado automaticamente pelo Visual Studio). Navegue à vontade pelas páginas de teste que você deve ter criado (espero que sim!). Depois, no Visual Studio, marque o teste manual como concluído:

Ao clicar numa das opções acima (e em seguida em Apply) você terá concluído o teste. Inspecione agora a janela de resultado da cobertura de código (Test | Windows | Code Coverage Results). Veja como a cobertura de código foi corretamente preenchida de acordo com as páginas que você navegou:

Testes Web e Testes de Carga

Testes Web (Web Test) e Testes de Carga (Load Test) também alimentam a cobertura de código. Faça seus testes e confira!

Outros tipos de testes

Veja como alguns dos outros tipos de teste disponíveis no Team System se comportam quanto à cobertura de código:

Testes Unitários de Banco de Dados: Esses testes nada mais são que o teste unitário convencional com algumas facilidades para a execução de T-SQL. Na verdade, por baixo dos panos eles são .NET puro. Assim, se por acaso invocarem trechos da sua aplicação então a cobertura de código refletirá tal fato;
Testes Ordenados: Como estes são nada mais que agrupadores de outros testes, estarão sujeitos às regras aplicáveis a cada um dos "sub-testes" que os compõem;
Testes Genéricos: Esses testes existem para que possamos testar componentes não- .NET ou que sejam externos à nossa aplicação. Assim, não faz sentido esperar que esses testes "sensibilizem" a cobertura de código.

Conclusão

A cobertura de código é um recurso muito importante da Test Edition do Visual Studio Team System, e está disponível para a maioria dos tipos de testes - não só para testes unitários. Use e abuse da cobertura de código!

Technorati Tags: VSTS,Team System,Test,Test Edition,Unit Test,Code Coverage,.NET

Pôsteres de Visual Studio Team System em português

Tue, 06 May 2008 01:54:22 GMT

Um MVP de Team System da África do Sul, Willy-Peter Schaub, teve uma grande idéia - criar pôsteres de referência, cobrindo vários aspectos do Visual Studio Team System. Como os pôsteres originais são em inglês, comecei no ano passado um trabalho com ele para traduzirmos o material para o português.

Para baixar os pôsteres, visite http://www.drp.co.za/Media/Posters/tabid/73/Default.aspx. Fique de olho, pois mais pôsteres em português estão a caminho!

Integração TFS - CA Harvest

Tue, 29 Apr 2008 21:35:31 GMT

Recentemente, participei do processo de adoção do TFS em um grande banco brasileiro. A equipe do projeto gostaria de utilizar o Team System - e em especial o TFS - para melhorar seu processo de desenvolvimento de software. Todos os envolvidos já conheciam a ferramenta e tinham ciência dos ganhos de produtividade e visibilidade oferecidos. Excelente, não?

Mas como nada na vida é tão simples assim, eles tinham um porém: o banco já havia adotado algumas ferramentas da Computer Associates (CA) para gestão do ciclo de vida. Essa decisão se deu, em parte, pela necessidade de integração com o mainframe. Dentre essas ferramentas, destaque para o CA Software Change Manager (anteriormente chamado de Harvest). Como o Harvest é a ferramenta de controle de versão "oficial" do banco, nosso desafio era integrar o TFS e o Harvest.

A solução

No cenário definido pelo banco, não havia a exigência de que toda e qualquer versão do código-fonte fosse mantida no servidor do Harvest. Ou seja, como o TFS oferece um controle de versão seguro e auditável, poderia ser usado durante toda a fase de desenvolvimento, sem precisar "conversar" com o Harvest. A integração se daria apenas nos milestones definidos pela equipe de projeto - ou seja, quando fossem "gerar um pacote" (ou "fechar uma baseline") para que as equipes de teste e homologação pudessem testar o produto.

Com esse requisito, a solução desenvolvida utilizou o Team Build para "fechar o pacote". Através de um conjunto de custom tasks do MSBuild, foi possível criar scripts de build que, de forma simples, interagiam com o Harvest.

Essas custom tasks encapsulam a API COM do Harvest (CHSDK), de modo que seu script pode conter tags tais como <Harvest.CheckIn> ou <Harvest.CreatePackage>. Simples assim :).

CodePlex!

Minha intenção é publicar esse código no CodePlex (assim que definirmos as questões legais e de licença do código-fonte). Avisarei aqui no blog quando tiver novidades. Fique atento!

De casa nova!!!

Sat, 29 Mar 2008 17:49:38 GMT

Depois de um looongo e tenebroso inverno, o blogueiro Igor Abade resolveu retomar suas atividades.

Agora, você pode meu blog sobre Visual Studio Team System aqui no Windows Live Spaces! http://igoravl.spaces.live.com/

Aponte seus leitores de RSS para o feed do meu blog: http://igoravl.spaces.live.com/blog/feed.rss

Aos leitores novos e antigos do meu blog: Bem-vindos! Teremos um longo e proveitoso caminho pela frente.

Um abraço,
Igor

Pesquisa Internacional sobre VSTS

Wed, 11 Apr 2007 04:36:36 GMT

Bock Hodges anunciou uma pesquisa internacional que está sendo feita pela MS para obter feedback sobre o VSTS. Há pesquisas para alguns idiomas específicos e até mesmo outras para países específicos

Aldo Donetti, lead PM on the VSTS globalization team, sent out email today about the newly released VSTS International Surveys. These complement the previously released English language survey. There are both language-specific and some country-specific surveys. If you use VSTS in one of the languages and/or countries below, it would be helpful to us for you to take the survey and let us know your opinion.

Para participar da pesquisa direcionada ao público brasileiro, clique aqui.

TFS Management Console

Sun, 08 Apr 2007 06:29:19 GMT

Tenho pensado já há algum tempo em como melhorar a experiência do usuário na administração do TFS. Quer dizer, acho que todos concordamos que a administração do TFS usando as (poucas) ferramentas existentes é, no mínimo, confuso.

Não foram poucas as vezes em que vi reclamações de usuários frustrados com o trabalho de procurar por diversas ferramentas de administração do TFS na internet para suprir as lacunas deixadas pela ferramenta. Ainda que realmente existam tais ferramentas, as queixas geralmente batem numa mesma tecla: deveria haver um "pacote" único de ferrramentas, que deveriam ser mais consistentes e fáceis de usar.

Há diversas ferramentas que facilitam o dia-a-dia dos administradores - como aquelas desenvolvidas pela Accentient e a já famosa TFS Admin Tool da Microsoft - mas falta a elas integração e consistência. Do ponto de vista de um desenvolvedor isso é compreensível - afinal, essas ferramentas foram feitas por pessoas diferentes em circunstâncias diferentes - simplesmente não há como integrá-las.

Ainda assim, nossos usuários estão acostumados com excelentes ferramentas de administração, como aquelas oferecidas pelos servidores SQL Server, Internet Information Services (IIS)e Exchange Server. Elas compartilham uma plataforma comum - MMC, ou Microsoft Management Console, - que foi desenvolvido com a meta de oferecer a desenvolvedores a possibilidade de criar ferramentas de administração consistentes e extensíveis.

Assim, minha pergunta é: Que tal se, ao invés de termos diversas ferramentas, separadas e inconsistentes, tivéssemos algo como o mostrado nas figuras abaixo?

Este é o TFS Management Console (pelo menos até alguém sugerir um nome melhor) - um projeto pessoal meu, que nasceu como uma prova-de-conceito mas que agora está "criando asas", indo para o CodePlex. Eu o imagino como uma plataforma com os recursos básicos - enumerar servidores e projetos, por exemplo - que tira proveito dos fabulosos recursos de extensibilidade oferecidos pelo framework do MMC (especialmente considerando o fato de que o MMC 3.0 suporta snap-ins gerenciados - que são realmente muito fáceis de se desenvolver em C# ou VB) para permitir que outros desenvolvedores criem extensões de uma maneira organizada e consistente.

Agora eu gostaria de saber: o que você acha dessa idéia? Se você já criou (ou pensa em criar) uma ferramenta para o TFS, usaria o TFS Management Console como plataforma?

Quais recursos você acha importantes? O que você gostaria de ver contemplado nesta ferramenta? Por favor, dê sua opinião - aqui neste blog ou diretamente no site do projeto. Farei de tudo para que todas as idéias, pedidos e sugestões sejam, dentro do possível, incorporadas ao produto final.

Microsoft Expression Web e Blend - Agora no MSDN Subscriptions!

Tue, 03 Apr 2007 19:06:32 GMT

(UPDATE: Assinantes do MSDN Premium com Visual Studio Team Suite receberão o pacote Expression Studio completo - incluindo as ferramentas de design de imagens.)

Acabei de ver um post no blog da Mary Jo Foley em que ela anuncia algo que, até então, a maioria achava impossível: a Microsoft incluiu nas assinaturas MSDN Premium as ferramentas da suíte Expression voltadas à criação de aplicações - Expression Web e Expression Blend. Mas nem todas as ferramentas serão disponibilizadas para os desenvolvedores:

Microsoft isn't planning to make Expression Design or Expression Media available as part of MSDN, however, company officials said.
"This is not a change in who these products are for," said Forest Key, director of product management for Microsoft's design tools. "It's ore about giving developers access to the tools" in case they want to see how they work and how they will dovetail with Visual Studio.

Expression Web já está disponível para download. Expression Blend deve ser liberada assim que estiver pronta, nas próximas semanas.

Redmond: D - 4 !!!

Tue, 06 Mar 2007 04:07:20 GMT

Pois é, daqui a apenas quatro dias estaremos chegando a Seattle e de lá para Redmond. Microsoft, se cuide!!! :-D

No período de 12 a 15 de março ocorre o 2007 MVP Global Summit, evento patrocinado pela Microsoft e que reúne MVPs do mundo inteiro, numa oportunidade única de troca de idéis e conhecimentos - além de podermos participar de palestras e bate-papos direto com as equipes de produto! Imagine só poder conversar com os caras que fazem o Visual Studio Team System, ver o produto direto no computador deles e conhecer o que vem por aí!

Por falar em oportunidade única, esta é provavelmente a última vez que Bill Gates fará uma apresentação pública como chairman da Microsoft. Tomara que consigamos tirar uma foto com ele (se bem que com a quantidade de MVPs que vão estar na fila, deve ser difícil... ;-) )

Fique ligado, blogarei diretamente de Redmond para contar tudo sobre o evento (claro, tudo aquilo que puder ser contado - muitas das palestras são confidenciais...)

Team Foundation Server Power Tools 1.2

Fri, 23 Feb 2007 06:22:52 GMT

Foi lançada a nova versão do pacote de ferramentas (anteriormente conhecido como Power Toys) que estende os recursos do Team Foundation Server.

Now Available: Team Foundation Server Power Tool v1.2
The February release of the Team Foundation Server Power Tool is now available for download. Formerly known as the Team Foundation Power Toy, these utilities pack too much punch to be considered toys.
In this release, among other things you'll find a process template editor that runs inside the Visual Studio IDE for customizing your own process templates. To use the editor, you must first install the Domain-Specific Language Tools for Visual Studio 2005 Redistributable Components.

Link para download: Team Foundation Server Power Tool