XAML: {x:null} vs Transparent

Depois de algum tempo a tentar criar um botão com uma imagem transparente que seja clicável em qualquer área, descobri que devia usar Transparent na propriedade Background ao invés de {x:null}.

Devo dizer que com esta descoberta, parece que encontrei o caminho da luz .... só não entendo porque num vi esta luz antes.

Strongly typed SignalR CommunicationService

Tenho usado o SignalR como "server support" nas minhas aplicações, sejam elas Silverlight, WindowsPhone ou Windows Store, mas, uma coisa que me aborrece é o facto de as chamadas ao servidor serem efectuadas com strings. Desta forma perdemos a capacidade de alterar a interface e em "compile time" sabermos todos os locais onde o método / propriedade é usado.
Ao usarmos strings estamos sujeitos a erros de digitação e com isso infidáveis horas a fazer debug até encontrar que o problema foi que escrevemos mal o nome do método ou do evento.

À umas semanas atrás resolvi dedicar-me a escrever uma interface com Expressions e Func que me permita usar a interface da Hub para executar os server-side methods.

Antes era assim que eu executava um método que não retornava dados do servidor:

public async Task ExecuteNonReturnMethod(string hubName, string methodName, params object[] args)
        {
            (...)
        }

Sempre que o usava tinha que fornecer a hubName, MethodName e os Parametros... tudo em strings. É fácil ver que os erros aconteciam MUITASSSSSS vezes.

A nova assinatura do método é:
public async Task ExecuteNonReturnMethod(string hubName, Expression> methodExpression)
{
            var methodCallExpression = methodExpression.Body as MethodCallExpression;
            if (methodCallExpression == null)
            {
                throw new InvalidOperationException("Need to provide a method to call.");
            }

            var methodInfo = methodCallExpression.Method;
            var methodName = methodInfo.Name;

            var i = 0;
            var body = (MethodCallExpression)methodExpression.Body;
            var parameters = new object[body.Arguments.Count()];
            foreach (var value in
                from MemberExpression expression in body.Arguments
                select ((FieldInfo)expression.Member).GetValue(((ConstantExpression)expression.Expression).Value))
            {
                parameters[i] = value;
                i++;
            }

            var clientProxy = _hubProxyList[hubName];
            await clientProxy.Invoke(methodName, parameters);
}

e é chamado desta forma:
public async Task CheckLocalUser(string externalUserId, string fullName, string userName)
        {
            return
                await
                this.Execute(
                    x => x.ValidateLocalUser(externalUserId, userName, fullName));
        }

Desta forma temos uma forma de invocar o método no servidor usando a interface e agora, sempre que alterar a interface obtenho erros em compile-time.

Esta foi a forma que encontrei para transformar uma invocação que tem que ser baseada em strings numa strongly typed.
Será que existe alguma forma mais simples de o fazer?


Paulo Aboim Pinto

Que a lavagem cerebral comece...

Hoje ao ler uns blogs deparei-me com este maravilhoso vídeo que mostras aos miúdos que não devem partilhar música, jogos e outros qualquer produto digital.
Não me lembro de nos anos 80 e 90 a Sonny, fabricante de gravadores de vídeo alguma vez se preocupar com os produtores de filmes ou com os actores, mas, hoje preocupa-se porque é uma das maiores distribuidoras de conteúdos digitais.

Nunca ouvi nenhum artista dizer que não ganha o suficiente por causa dos rádios de dois decks que possibilitavam gravar de uma cassete para outra ou ainda nenhum escritor dizer que o facto dos seus leitores lerem de livros emprestados fazia com que ninguém comprasse os seus livros.

A industria da distribuição de conteúdos é que não está a actualizada ao mercado actual e as necessidades das pessoas, mas, está ainda agarrada a persupostos antigos, modelos de negócios desajustados à realidade que já não retornam a mesma margem de lucro.

Este vídeo tem o propósito de educar, mas, ao contrário disso, está a tentar fazer uma lavagem cerebral as nosso jovens e empurralos a um consumismo desmesurado e sem sentido.

Aqui está o vídeo


Fonte: MPAA e RIAA querem fazer Lavagem Cerebral desde o Jardim Infantil

Testar ou não testar....

No projecto que estou envolvido  temos a obrigação de manter uma percentagem  muito elevada de cobertura por testes unitários e desde à algum tempo que tenho vindo a desafiar os meus colegas sobre este assunto, o que temos e o que não temos que testar no nosso software.

Muitos de vós irão dizer sem pensar: "Temos que testar tudo!", mas, aqui é que reside o problema, o que é tudo?

Será que esse tudo quer dizer que devo testar se a minha ViewModel tem o [ImportingConstructor] no constructor ou se tem o [Export] na class, ou ainda se todas as propriedades tem o "OnPropertyChange"?
Outros que testam classes que são gateways entre o client side e o server side que o fazem é testar que o método é chamado com os mesmos parametros recebidos, será que estão a trazer valor acrescentado aos nossos testes ou estaremos só a aumentar a coverage dos testes para nosso regorzijo?

Outro ponto que queria tocar é que por vezes para testar duas linhas de código que escrevemos em 30s, demoramos 20 minutos ou mais a preparar o teste. Será que este teste vale a pena ser escrito?

Não quero com estas palavras  que pensem que eu sou contra os testes unitários, muito pelo contrário. O que acho é que há limites para o que devemos ou não testar e se estamos a perder mais tempo a preparar testes que a programar, algo vai mal na arquitectura da nossa solução.

Agradeço os Vossos comentários.
Paulo Aboim Pinto

Uma semana com Windows Surface PRO

Boas,

Muito há a dizer sobre este novo equipamento. Como ele é bonito, funcional, que tem uma bateria incrível que podemos ficar até 5h a trabalhar, a forma como magnéticamente encaixa perfeitamente com o teclado, etc., mas, ao invés disso vou falar de como tenho o usado.

Uma das principais razões para comprar este equipamento foi para ocupar de uma forma racional os 30m que levo todo os dias de casa para o trabalho e mais 30m do trabalho para casa. Estava a usar o meu vulgar laptop que pesa 3Kg, Não é mau, mas, o espaço no comboio num é grande e apesar de não ser muito grande, o laptop as vezes era grande mais para o espaço que tinha disponível.
Depois de pesquisar um pouco reparei que todos o que tem o Surface Pro falavam muito bem da sua utilização em conjunto do Visual Studio. Vi vídeos e mais vídeos e decidi que tinha todas as condições para comprar um e que o dinheiro não seria deitado na rua.

Uma semana depois posso dizer que tenho instalado no Surface PRO o mesmo ambiente de desenvolvimento que tenho no meu laptop: Visual Studio 2012, Resharper, Git for TFS Online, SQL Server 2008 Express e tirando o facto do teclado num ser completo e do monitor ser muito mais pequeno, não vejo qualquer difereça entre desenvolver no Surface PRO ou no meu laptop.

Diria que esta máquina não é a indicada para uso regular, isto é como máquina de trabalho, mas, resolve bem o problema da portabilidade por pesa pouco mais de 1Kg.
Se havia dúvias antes de o comprar, agora já não as tenho e o Surface PRO me acompanha agora todos os dias para o trabalho onde posso ser produtivo também no comboio.


beijos e abraços
Paulo Aboim Pinto

Consegui configurar o continuous build no TFS Git com uma solução: Win8 App + ASP.NET Backend.

Até aqui conseguia fazer isto muito bem se a solução fosse puramente no TFS, mas, ontem à noite consegui com os projectos Git no TFS Online e estou muito contente.

Gosto do Git como source-controller, mas, falta-lhe o resto que gosto no TFS como a possibilidade de associar Tasks a uma Check-In de uma forma simples e toda a gestao do projecto baseada no trabalho desenvolvido.
Sei que existem diversas ferramentas que ajudam o Git a ter estas funcionalidades, mas, porque quero outras ferramentas se o TFS faz isso muito bem? Vou esperar pela integrações de gestão de projecto que a equipa do TFS venha a introduzir no Git!

O que ficou ainda por fazer é deployment automático para o Azure. Ai continuamos com problemas devido a erros nos target files que estão no Git (acho eu), pois, a mesma solução fazia o deployment sem problemas a partir no TFS. Vamos esperar para ver.

Outra coisa que noto que falta é poder correr os scripts de Code-First no final do deployment em Azure. Em TFS temos um campo onde podemos colocar o Deployment Script que fazemos download do dashboard azure, mas, nos ecrans de definição do build em Git não temos essa opção, pelo que ainda não deve estar implementado.
Felizmente a partir do publish do projecto ASP.NET tudo funciona lindamente. Ainda espero um dia termos uma forma de a cada check-in fazer um push da solução Win8 para a store, nesse ponto teremos um serviço completo.

O objectivo deste trabalho era ter um luz verde no continuous build do Git e isso já está. Agora é colocar os projectos de testes e garantir que qualquer alteração não está a produzir problemas secundários na solução.


beijos e abraços
Paulo Aboim Pinto

Este blog vai ser um pouco mais técnico....

Este blog tinha como função ser generalista, onde eu falava sobre Futebol, Política sou sobre qualquer coisa que me vinha à cabeça, mas, de uma forma geral não tinha muitas conversas técnica, pois, para tal tinha outro blog na comunidade PontoNetPT. Infelizmente essa plataforma não está disponível à algum tempo (vários meses) e parece que ninguém é capaz de resolver o problema, pelo que vou começar a usar este blog para os meus devaneios técnicos.

Irei também falar sobre a minha experiência como emigrante (estou neste momento em Zurique, Suiça) e falar um pouco do trabalho que estou a desenvolver junto da Roche Diagnostics, sem entrar em pormenores que quebrem a confidencialidade.

A namorada está grávida, pelo que irei falar um pouco sobre esta maravilhosa experiência.


Obrigado a todos
Paulo Aboim Pinto