15 anos atrás a Microsoft tomou a decisão de comprar oque viria a ser tornar um dos mais conhecido software de versionamento de arquivos: O Source Safe, que mais tarde viria a ser tornar Visual Source Safe.
Do nosso site interno (MSW):
|
|
November 15, 1994—Microsoft announces the acquisition of One Tree Software, a privately held company based in Raleigh, N.C., and maker of SourceSafe. Laura Yedwab, product unit manager of the Developer Division Repository Group at the time, said, "This spring we went through a 'make versus buy' decision. We did a competitive analysis of all the major versioning and configuration management tools on the market." SourceSafe was the clear winner and replaced Delta in Microsoft's product lineup.
One Tree president Brian Harry joined Microsoft after the acquisition. He and his brother Craig are still with the company, based in Raleigh. This week's photo features a shot of the original SourceSafe software recently added to the Archives collection. |
Curiosidade para muitos é que internamente os times de produto não usam o Visual Source Safe para gerenciar versionamento de arquivos. Atualmente alguns times estão usando o TFS (Team Foundation Server), porem a grande maioria ainda usa SourceDepot.
No wikipedia em inglês:
Microsoft in-house use
Although "eating their own dog food" is often said to be part of Microsoft's culture, VSS appears to be an exception; it is widely rumored, that very few projects within Microsoft rely on VSS, and that the predominant tool is SourceDepot. According to Matthew Doar
Microsoft itself used an internally developed version of RCS named SLM until 1999, when it began using a version of
Perforce named
SourceDepot.
The Microsoft Developer Division is now using the new Visual Studio Team System for most of its internal projects, although a VSS transcript implied that other large teams use "a mix of customized in-house tools."
Forte abraço.
A Microsoft anunciou hoje a compra do suite Teamprise (Teamprise é uma divisão da SourceGear) que permite a colaboração multi plataforma para o Team Foundation Server.
Teamprise suite resolve o problema de muitos desenvolvedores e organizações que possuem diferentes plataformas e ambientes de desenvolvimento. Teamprise’s Client Suite permite por exemplo que desenvolvedores que usam Eclipse em diferentes SO incluindo Windows, Unix, Linux e Mac OS X construam aplicações enquanto utilizando os rescursos do Microsoft Visual Studio Team Foundation Server.
Mais informações em InfoWorld ou Microsoft PressPass
Abraços.
Muitas pessoas ainda não estão usando o poder deste recurso chamado yield. Porque ? Talvez porque muitas pessoas ainda não tenham entendido a utilização deste recurso.
Neste blog tentarei, usando um exemplo bem simples, mostrar um pouquinho deste podereoso, porem ainda não muito utilizado ou entendido recurso introduzido no .net framework 2.0.
Sempre que usamos um "foreach", necessitamos usar um tipo que implemente a interface IEnumerable ou IEnumerable<T>, todos os arrays e muitas coleções (ArrayList, List<T>) implementam IEnumerable, esse é o motivo no qual podemos usar esses tipos num "foreach"
Exemplo:
IEnumerable<int> numbers = new int[] { 11, 29, 33, 7, 54, 65, 16, 80 };
foreach (int i in numbers) { Console.WriteLine(i); }
Nesse exemplo vemos que para o foreach funcionar corretamente o IEnumerable foi criado e preenchido com todos os items, para então ser possivel retornar essa colecão de informação.
Agora imagine um cenário no qual em caso você encontre uma determinada informação seu trabalho termina e o restante das informações nao llhe servem de nada. Nesse cenário vamos simular que para gerar essa lista é necessario operações longas que tomam tempo.
Por exemplo: Numa lista de numeros gerados numa operação de potencia, você gostaria de saber qual o indice que o número 32 se encontra.
static
void Main(string[] args)
{
Stopwatch stopWatchTimer = Stopwatch.StartNew();
Console.WriteLine("Inicio da Demo");
int
index = 0;
foreach (int i in Potencia(2, 10))
{
if (i >= 32)
{
Console.WriteLine("Numero 32 foi encontrado no indice: " + index);
break;
}
index++;
}
stopWatchTimer.Stop();
Console.WriteLine("Tempo total gasto: " + stopWatchTimer.Elapsed);
Console.Read();
}
public
static List<int> Potencia(int num, int potencia)
{
List<int> lista = new List<int>();
int result = 1;
for (int i = 0; i < potencia; i ++ )
{
Thread.Sleep(1000); // Simula uma operação cara
result = result * num;
lista.Add(result);
}
return lista;
}
Neste exemplo sabemos que teremos 10 operação uma vez que estamos elevando 2 a 10 (2, 4, 8, 16, 32, 64, 128, 256, 512, 1024), cada operação levaria nessa simulação 1 segundo (totalizando 10 segundos), porem queremos saber qual é o indice do numero 32, como optimizar meu código ? Resposta: Usando a magica do yield.
No exemplo acima teriamos o seguinte output:
Inicio da Demo
Numero 32 foi encontrado no indice: 4
Tempo total gasto: 00:00:10.0037011
Vamos alterar nossa função para utilizar yield:
public
static IEnumerable Potencia(int num, int potencia)
{
int result = 1;
for (int i = 0; i < potencia; i++)
{
Thread.Sleep(1000); // Simula uma operação cara
result = result * num;
yield return result;
}
}
Ao executar novamente nosso código:
Inicio da Demo
Numero 32 foi encontrado no indice: 4
Tempo total gasto: 00:00:05.0046293
A execução do código passou de 10.0037011 segundos para 05.0046293 segundos. Um ganho por volta de 50% do tempo.
Entendendo a diferença entre as execuções:
|
Implementação normal |
Implementação Yield |
- Chamador chama a função
- Função executa e retorna a lista
- Chamador usa a lista
|
- Chamador chama a função
- Chamador requisita o item
- Próximo item é retornado
- Volta para o passo #2
|
Conclusão
Yield pode tornar seu código muito mais eficiente. Este recurso esta disponivel desde o .NET 2.0, não há mais motivos para você não estar usando ainda.
clique aqui para ler um outro post (em inglês) muito interessante sobre yield.
Forte abraço.
Nunca ouviu falar em WiX? WiX ou windows installer XML (pronuncia-se "wicks") é um framework para construção de instaladores MSI (Windows Installer setup) ou merge modules MSM (Pacote de arquivos compartilhados pelo instalador). WiX foi o primeiro projeto open source da Microsoft.
WiX framework fornece integração com compilação de linha de comando para desenvolvedores que usam MakeFile ou integração com MSBuild de dentro do Visual Studio.
Muitos produtos dentro da microsoft utilizam esse framework para a construção de seus aplicativos de setup. SQL Server e Exchange Server são alguns exemplos.
Clique aqui para baixar o WiX framework
Clique aqui para ler um tutorial completo sobre WiX
Essa semana precisei alterar uma parte do nosso setup para adicionar uma condição para a instalação de alguns arquivos. Essa condição se baseava num determinado valor de uma chave no registry. Em caso o setup fosse capaz de localizar essa entrada no registry e o valor da chave fosse 1, certos arquivos eram copiados durante a instalação, caso contrario esses mesmo arquivos não deveriam ser copiados. Perdi um tempão tendando entender porque minhas mudancas não estavam funcionando corretamente, quando percebi que o problema estava ligado pelo fato de eu estar usando uma maquina 64 bits, porem eu nao estava especificando essa opção na minha propriedade de leitura da registry no WiX.
Como podemos ver no exemplo abaixo Win64='yes' para a correta leitura do registry.
<
Property Id="MINHACHAVE">
<RegistrySearch Id='MinhaChave_REGISTRY' Type='raw'
Root='HKLM' Key='Software\Microsoft\MeuProduto\V14' Name='MinhaChaveEnabled' Win64='yes' />
</
Property>
Isso é necessario para que o windows localize a entrada debaixo do nódulo Wow6432Node.
No exemplo mostrado abaixo, caso o setup encontre a chave e a chave tenha valor 1 (como a chave é um dword devemos comparar contra '#1'). Entao o setup criará um atalho no desktop, caso a chave não existe nenhum atalho sera criado.
<
Component Id='Aplicativo' Guid='155FCD2B-ED3C-44c8-A769-02AD23E56397'>
<
File Id='Aplicativo' Name='Aplicativo.exe' DiskId='1' Source='Aplicativo.exe' KeyPath='yes'>
<
Shortcut Id="startApp" Directory="DesktopFolder" Name="Aplicativo" Advertise="yes" />
</
File>
<
Condition>MINHACHAVE = "#1"</Condition>
</
Component>
O exemplo acima mostra que podemos criar propriedades no nosso WiX e essas propriedades podem ser baseadas na existencia de um arquivo, de uma determinada informação do registry ou qualquer outra informaçào que precisamos saber durante o setup. Uma vez que temos essa propriedade definida, podemos usa-la como condição para uma detemrinada ação.
Para baixar um exemplo completo da utilização de condição durante a instalação. clique aqui
Outro exemplo. Validando uma versão especifica do .Net framework. clique aqui
Este foi so um pequeno exemplo deste poderoso framework chamado WiX.
Espero que tenha gostado.
Forte abraço.
Programação multithread exige muitas vezes que o programador implemente seu próprio código para garantir sincronização e thread segura. Muitas vezes esquecemos que num ambiente multi thread, threads distintas podem estar acessando informações de maneira incorreta.
Vejamos no exemplo a seguir um código multi thread sem a utilização de mecanismo de sincronização.
Não podemos garantir o output desse código uma vez que não temos nenhum mecanismo de sincronização entre threads. O output desse código seria algo parecido com isso:
0134567892
Para garantir sincronização entre as threads, necessitamos adicionar um semáforo. Neste caso utilizaremos o Lock. Neste primeiro exemplo vamos utilizar o lock de uma maneira incorreta para entao entendermos porque esta utilização não é à adequada.
Abaixo mesmo código, agora com o lock:
Com essa alteração garantimos que 100% das vezes o código executado terá o seguinte output:
0123456789
Você deve estar se perguntando o que esta errado na utilização do Lock(this) ?
Quando você utiliza lock(this), a visibilidade do objeto locado é a mesma que a visibilidade da classe, neste caso se sua classe é publica, o objeto locado esta visivel em qualquer lugar. Isso torna possivel a introdução de um deadlock na sua classe por qualquer parte do código, tornando muito dificil o diagnóstico do deadlock.
Solucionar o problema é muito facil. Basta adicionar um objeto de sincronização privado e utilizarmos este no nosso lock como mostrado abaixo:
Lembrete:
- lock(this) é um problema se a instância pode ser acessada publicamente.
- lock(typeof (MyType)) é um problema se MyType é acessado publicamente.
- lock(“myLock”) é um problema se qualquer outro código no mesmo processo estiver usando a mesma string.
Melhor prática é definir um objeto privado de sincronização ou um objeto estático privado para proteger dados comun entre todas as instancias.
Espero que essa dica seja útil,
Um grande abraço.
Hoje um amigo meu me perguntou como ele poderia habilitar a visualização dos espacos (whitespaces) no Visual Studio, ja não foi nem a primeira e nem a segunda pessoa que me pergunta isso e o engraçado foi que ele veio me questionar exatamente como as outras pessoas tambem vieram: "Estou no Visual Studio, menu, Tools, Options, aonde é mesmo que eu posso mudar a opção de habilitar a visualização dos whitespaces ?"
Muitas pessoas acreditam que essa opção foi removida do Visual Studio, inclusive já vi em alguns blogs falando que isso foi removido e dando como alternativa uma alteraçao de chave no registry. É verdade existe uma chave no registry onde podemos habilitar/desabiltiar essa opção : HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\?.?\Text Editor\ , onde "Visible Whitespace" = 0 (desligado) e = 1 (ligado)
Na verdade, continuamos com a opção de efetuar essa tarefa via Visual Studio:
Menu Tools -> Options... -> Environment -> Fonts and Colors -> Visible White Space -> Troque a cor do Item foregorund.
Se você achou ambas opções um pouco trabalhosas, existe uma terceira opção onde tenho certeza que você vai gostar. O uso das teclas de atalho. Sim existe uma tecla de atalho especifica para isso.
Tente você mesmo: CTLR+R+W
Fica aqui minha dica,
Um grande abraço.
Algum tempo atras estava conversando com um amigo que estava comentando sobre os problemas que a empresa/projeto em qual ele estava trabalhando estava enfrentando em relação a quantidade de check-ins com código extremamente pobre ou fora do padrão em que estavam tentando adotar e o pior de tudo: com um alto número de bugs. Esse amigo meu perguntou quais estratégias usamos aqui na Microsoft para minimizar esses tipos de problemas e garantir que exista um padrão mínimo de codificação para aumentar a qualidade do código que esta sendo submetido e tambem melhorar a manutenção futura do codigo.
Comecei a explicar que existem varios mecanismos, desde ferramentas e metodológias que a Micrososft usa, mas foi quando comecei a falar sobre um exercício que fazemos aqui chamado Code Review que ele ficou realmente interessado. Existem inúmeros benefícios de fazer e receber code review antes que o código seja submetido (check in), dentre eles: validar se a funcionalidade esta sendo alcançada, validar se o código esta seguindo os padrões estipulados pelo time, validar se o códgio é entendivel por outros desenvolvedores, obter uma opinião externa sobre o código escrito, entender melhor partes do sistema/código que você não esta diretamente trabalhando, encontrar possíveis bugs que o desenvolvedor pode estar introduzindo no sistema, aprender com os outros, etc, etc, etc...., como falei existe muitas vantagens e seria muito difícil listarmos todas.
Aqui no meu time antes de fazermos check-in, temos a orientação de receber pelo menos 2 code reviews, ou seja 2 desenvolvedores vão analisar o código e fornecer comentarios (caso exista algum). O code review é algo que todos podem se beneficiar, portanto tente estar sempre aberto as sugestões de quem esta fazendo o code review. Muitas vezes ficamos um pouco defensivos sobre o que estam falando do nosso código e entendemos o code review como duras criticas ou sugestões não necessarias. Uma dica é tentar sempre ver quem esta revisando seu código como seu aliado, ele pode estar te ajudando a evitar bugs. Inumeras vezes eu recebi code review eu pensei que tal sugestão seria desnecessária, aprendi que se nao tivesse aceitado a sugestão teria problemas futuros com meu código, ou seja a melhor estratégia durante code reviews é deixar seu ego de lado e tirar o maximo de proveito da situação.
Além de todos esses benefícios, o code review também fornece uma maior confiança ao desenvolvedor no momento do check-in. A introdução de um bug no sistema nunca é recebida com bons olhos, mas existe sempre a desculpa de que o código foi revisado e ninguém foi capaz de encontrar o bug durante o code review. :-)
Uma outra dica que pode ajudar a evitar muitos bugs e forcar uma padronização de escrita de código é a utilização de ferramentas de análise de código. Existem diversas ferramentas no mercado sobre isso, por exemplo: aqui no meu time antes de enviarmos nosso código para code review, usamos 2 ferramentas que ajudam na validação se o código esta seguindo um padrão mínimo de qualidade.
- StyleCop - Somente para código C#, vai analisar seu código e sugerir melhorias e padronizações.
- FxCop - Analisa seu assembly e identifica possiveis problemas sobre localização, performance, segurança, etc.
Ambas ferramentas são totalmente gratuitas e possuem uma utilização muito facil, em minutos você pode evitar serios bugs. Outro exemplo de ferramenta muito popular para esse tipo de exercicio é o Code Auditor, essa ferramenta é bem mais completa do que o StyleCop por exemplo e suporta outras linguagem alem do C#, o lado ruim é que não é uma ferramenta gratuita. :-(
É isso ai pessoal, fica aqui a minha dica sobre o exercício de fazermos code review antes de efetuarmos qualquer check-in, caso você/seu time também esta passando por um problema parecido e gostaria de compartilhar sua experiência comigo, aguardo seu email.
Abraços.
Olá Pessoal, meu nome é Gustavo Varo e eu sou desenvolvedor na Microsoft Corp. em Redmond no time de produto Exchange Server. Estarei usando esse espaço para compartilhar dicas e informações que acredito serem de interesse/importância para você desenvolvedor.
Muitas pessoas tem a curiosidade de saber como é o ciclo de desenvolvimento de software dentro da Microsoft e como isso é diferente de uma outra empresa de desenvolvimento. Tentarei compartilhar com vocês um pouquinho de como é meu dia a dia de desenvolvedor aqui na Micrososft e quais as praticas e modelos que usamos por aqui, mais especificamente no Exchange.
Um grande abraço e bem vindo,
Gustavo.
