using System.Reflection; » .net

Visual Studio AddIn

caxaria — Mon, 14 Sep 2009 10:21:23 +0000

Quem trabalha com TestDrivenDevelopment sabe que a pior parte de conseguir uma boa code coverage é que há alguns testes que são demasiado entediantes para se estarem sempre a fazer… Infelizmente, não os fazendo, a % de code coverage desce, o que leva a que os outros testes – estes mais importantes – também passem um pouco despercebidos.

Para ajudar na criação deste tipo de testes, estive há uns meses a trabalhar com uma biblioteca de geração automática de testes, STDL. Esta biblioteca, apesar de ser bastante interessante, implicava ainda algum trabalho manual para que os testes fossem gerados.

Para ajudar a combater isso (e para aprender um pouco mais sobre o ecosistema do VS), passei um fim de semana a criar um addin para o visual studio. Este addin acrescenta ao botão direito do rato uma nova opção para gerar uns stubs para os testes STDL (faz um pouco mais, por inspecção da classe em que se clica mas… .

Hoje lembrei-me disso e achei que seria interessante colocar aqui umas referências pois nunca se sabe quando irei precisar de gerar testes em .net novamente

Podem ver mais neste post, sacar uma beta release aqui ou ver o código aqui.

Se acharem a plataforma interessante, falem com o Neville Grech na mailing list para ver se o projecto recomeça… Eu era capaz de fazer mais uma ou duas linhas de código

F#

caxaria — Fri, 14 Nov 2008 10:54:15 +0000

Para mais tarde recordar

Yahoo Vs Microsoft

caxaria — Wed, 22 Oct 2008 09:01:42 +0000

Apesar de não ter escrito nada de novo, acho que o Phil Wright resumiu tudo perfeitamente:

Yahoo have announced they are cutting 10% of its global workforce, about 1500 people, as it tries to cope with its ongoing problems. They also reported a 64% drop in third quarter profits and only a 1% increase in revenue over a year ago(…) Remember this is the same company that turned down a $47.5bn offer from Microsoft last January. I wonder if Jerry Yang still thinks that offer ‘undervalued the company’. This is where the problem of having the original founder as CEO really causes problems.

E, já que vão ao site, aproveitem para experimentar os controlos .net que ele vende. Ah, e alguns são grátis!

Aplicações ‘Single-instance’

caxaria — Mon, 04 Aug 2008 11:15:14 +0000

Podem ver aqui.

Plugins: Shell

caxaria — Thu, 31 Jul 2008 14:33:18 +0000

Depois de terminadas as férias (incluindo as férias mentais), está na altura de recomeçar a escrever sobre coisas mais técnicas, como os plugins.

O próximo passo vai permitir que o primeiro grande objectivo se aproxime: permitir que os plugins adicionem elementos à interface usando a ‘Shell’, que representa a aplicação vista pelos olhos dos plugins. A partir desta classe vai ser possível adicionar elementos aos forms, abrir novos documentos, lançar eventos para outros plugins, etc:

public Shell(IMainForm mainForm)
{
    lock(typeof(Shell))
    {
        if(_instance != null)
            throw new InvalidOperationException();
        _mainForm = mainForm;
        _pluginManager = new PluginManager();
        _documents = new Documents(this);
        _instance = this;
    }
    _dataAccess = new DataAccess();
    InitializePlugins();
    Events.SafeFire(Initialized, this, new ShellEventArgs(this));
}

As classes descritas até agora (parte 1 e parte 2) estão num projecto sem qualquer acesso a forms, não incluindo o ‘System.Windows.Forms’ nem qualquer assembly parecida. Por isso o construtor da ‘Shell’ recebe um objecto do tipo IMainForm, que será o ponto de passagem para o mundo real ou, no neste caso, o form.

Depois de garantir que apenas uma instância da classe é inicializada – pois não seria desejável que os plugins pudessem inicializar Shell’s a gosto – iniciamos uma série de classes que irão tratar de diferentes aspectos da aplicação: Acesso a dados, gestão dos documentos, etc, acabando com a inicialização dos plugins e acabando a lançar um evento, representando o final da inicialização da ‘Shell’.

Sendo que as outras classes serão descritas posteriormente, resta mostrar o que se faz na inicialização dos plugins:

private void InitializePlugins()
{
    _loadedPlugins = _pluginManager.LoadPlugins();
    foreach (IPlugin plugin in _loadedPlugins)
    {
        plugin.Initialize(_instance);
        try
        {
            plugin.Initialize(_instance);
        }
        catch (Exception)
        {
            //Could not initialize plugin
            //TODO: report back result of process.
        }
    }
}

Como no PluginManager, em que ao invocar o plugin se tinha o cuidado de apanhar qualquer excepção, aqui, ao chamar o método de inicialização, apanhamos qualquer excepção que possa ocorrer de modo a salvaguardar a aplicação. Novamente, fica por fazer alguma forma de conseguir mostrar ao utilizador que houve plugins que falharam mas isso será feito posteriormente, assim que o código nos mostrar como.

Finalmente, também temos de actualizar a interface do IPlugin:

public interface IPlugin
{
    void Initialize(Shell shell);
}

E, deixando assim, o código quase que compila e, melhor que tudo, quase que corre! O próximo passo será realmente colocar o código a correr e com um plugin a introduzir qualquer coisa no ecrã!

I/O Assíncrono

caxaria — Wed, 09 Jul 2008 11:02:08 +0000

Hoje a ler a revista MSDN online reparei num artigo que fala sobre implementar I/O assíncrono usando delegados para os callbacks. Imediatamente lembrei-me do projecto que fiz na Inosat, em que para conseguir rede, GPS ou GRPS no dispositivo móvel, usei um sistema parecido com este.

A maior diferença é que, em vez de declarar dois métodos para callback – um em caso de sucesso e outro em caso de falha – usei apenas um, retornando sempre um valor do tipo Result. Por exemplo, se virem no artigo, o autor para o método:

   1: public static string ReadAllText(string path);

define a seguinte assinatura:

   1: public static void ReadAllTextAsync(string path, Action<string> success, Action failure);

em que o primeiro método é chamado se o método correr como esperado, o segundo é invocado se houver algum problema pelo caminho. No meu caso, a definição seria algo como:

   1: public static void ReadAllTextAsync(string path, Result<string> success);

em que a classe Result é:

public class Result
{
    private readonly T _value;
    private readonly bool _valid;
    private readonly string _error;
  
    private Result(T value)
    {
        _value = value;
        _valid = true;
    }
  
    private Result(string error) : this()
    {
        _error = error;
    }
  
    private Result()
    {
        _valid = false;
    }
  
    public static Result Failed()
    {
        return new Result();
    }
  
    public static Result Failed(string error)
    {
        return new Result(error);
    }
  
    public static Result Success(T value)
    {
        return new Result(value);
    }
  
    public T Value
    {
        get { return _value; }
    }
  
    public bool Valid
    {
        get { return _valid; }
    }
  
    public string Error
    {
        get { return _error; }
    }
}

Isto permite que o Result seja usado para notificar se o método teve sucesso ou não e, caso não tenha, que se possa passar o erro que se encontrou.

A diferença que encontro nas duas abordagens é que, no meu caso, quem trata do resultado tem de verificar se a operação teve sucesso chamando o result.Valid. No caso da implementação que está na revista, cada método sabe se o resultado teve sucesso ou não. Para os puristas que defendem a abolição do uso de If’s (já trabalhei com alguns ), isto é puro ouro!

Plugins: PluginManager

caxaria — Wed, 09 Jul 2008 09:19:44 +0000

O primeiro problema que tenho de enfrentar para conseguir usar um sistema de plugins é conseguir identificar os plugins que temos disponíveis e os inicializar. Para isso vou criar o PluginManager.

De alguma forma tenho de definir como é que os plugins serão descobertos pela aplicação: Lidos automaticamente de uma directoria pré-definida, previamente registados usando uma UI na aplicação, ficheiros de configuração, etc. Como não quero ter de decidir isso para já, vou implementar a forma mais fácil que me consiga lembrar e, tendo o cuidado de não ter o uso desta implementação especifica ‘hard-coded’ em lugar algum, vou permitir que mais tarde se possa mudar o plugin manager (quem sabe usando.. um plugin!)

public interface IPluginManager
{
    IPlugin[] LoadPlugins();
}
  
public interface IPlugin
{
}

Temos então uma interface para o PluginManager que apenas tem um método, que devolve todos os plugins que foram encontrados.

Para a primeira implementação do PluginManager, segui o caminho mais simples: Primeiro procuro na directoria da aplicação por todas as dll’s que existam:

List  result = new List();
DirectoryInfo directoryInfo = new DirectoryInfo(Application.StartupPath);
FileInfo[] files = directoryInfo.GetFiles("*.dll");

De seguida, em cada ficheiro, procuro por classes que implementem a interface IPlugin:

foreach (FileInfo file in files)
{
    Assembly assembly = Assembly.LoadFile(file.FullName);
    foreach (Type type in assembly.GetTypes())
    {
        Type[] interfaces = type.GetInterfaces();
        foreach (Type interfaceType in interfaces)
        {
            if (interfaceType == typeof(IPlugin))
            {
                ...
            }
        }
    }
}

Basta depois criar instâncias destas classes, retornando-as no final.

ConstructorInfo constructor = type.GetConstructor(Type.EmptyTypes);
try
{
    if (constructor != null)
        result.Add((IPlugin) constructor.Invoke(new object[0]));
}
catch (Exception)
{
    //Could not load plugin
    //TODO: report back result of process.
}
break;

Aqui, após procurar o construtor sem argumentos, o único cuidado a ter é, ao invocar o construtor, apanhar todas as excepções que possam ocorrer. Isto, na verdade, deverá ser um cuidado a ter sempre que no código vá invocar algo num plugin, pois temos de assumir que, eventualmente, algum plugin irá estar menos bem implementado, prevenindo assim possíveis problemas na aplicação.

Para já as excepções encontradas ao invocar os plugins são ignoradas mas, após a implementação do host/controller da aplicação, vamos arranjar uma forma de apresentar feedback ao utilizador sobre as operações dos plugins.

Já agora, se tiverem a usar a framework 3.5, vejam antes aqui como initializar os plugins usando o novo namespace System.AddIn. Reduz-se esta classe a 3 linhas de código!

log4net – Event Viewer

caxaria — Tue, 08 Jul 2008 12:48:05 +0000

Para o projecto em que estou envolvido desde Janeiro, desde cedo fiz questão que fossem usados muitos processos relacionados com o desenvolvimento para, no final, facilitar o processo de manutenção.

No top 3 destes processos estão, sem qualquer sombra de dúvida:

Uso de source control (SVN)
Integração contínua
Log4net

Desde que usei o log4net na Inosat que acho que é uma ferramenta indispensável para a grande maioria* dos programadores. Desde que a aplicação foi instalada nos servidores que, invariavelmente, todos os problemas podem ser identificados usando os logs para verificar o que se passou.

Do site:

log4net is a tool to help the programmer output log statements to a variety of output targets. In case of problems with an application, it is helpful to enable logging so that the problem can be located. With log4net it is possible to enable logging at runtime without modifying the application binary.

Para além de ter o log básico para ficheiro, pode ser usado para fazer log para qualquer outro output imaginável, bastando para isso alterar o ficheiro de configuração da aplicação/serviço/website. Pode-se, por exemplo, mandar todos os logs de determinado nível – ex Error – por email, UDP, Event Viewer, etc.

No caso do projecto em que estou envolvido a BT pediu que o log fosse colocado no Event Viewer do windows para que eles pudessem monitorizar de forma automatizada. Um pedido destes, numa altura em que nos estávamos a preparar para iniciar a fase de testes pré-live, seria algo que nos obrigaria a mudar bastante o código para acomodar o novo tipo de logs. Felizmente, usando o log4net, bastou mudar o ficheiro de configuração**.

*Digo a grande maioria pois não quero generalizar mas… vá lá, 99,99%

**Bastou.. quer dizer… No principio não funcionou pois websites e services não têm permissão para criar Queues no ‘Event Viewer’. Para este problema, basta inicializar a Queue numa ‘custom action’ do instalador do site/serviço. A partir daí, visto que para escrever para o ‘Event Viewer’ não são precisas permissões especiais, tudo funcionou até nos servidores super-restritos da BT.

Plugins: O inicio

caxaria — Mon, 07 Jul 2008 14:27:05 +0000

Ultimamente tenho andado a trabalhar num pequeno projecto pessoal que entretanto decide partilhar.

O objectivo deste projecto é fazer uma aplicação semelhante ao Outlook em termos de interface mas, em vez de tratar de emails, esta aplicação seria direccionada para… qualquer coisa.

Este qualquer coisa não está aqui apenas porque não decidi sobre o que quero fazer a aplicação mas sim porque quero que seja possível que se consiga alterar completamente o alvo da aplicação, bastando para isso alterar os plugins registados na aplicação.

Se, por exemplo, eu fizer um plugin para gerir a minha colecção de DVDs’, nada impede que alguém faça um plugin para gerir a sua biblioteca de livros. Hey, e porque não fazer um plugin para gerir emails? E porque não ter isto tudo na mesma aplicação, com os plugins a comunicarem uns com os outros?

Aqui não há nada certo, apenas que a interface respeita a barra da esquerda – tal como o outlook - e que os documentos – sejam eles o que forem, aparecem à direita. Os plugins, no final, poderão interagir uns com os outros, não havendo qualquer restrição ao que será possível fazer com eles.

Assim, a primeira coisa que fiz foi a interface. Como podem ver na imagem, o nosso form principal é bastante… err, simples!

Tenho um ‘SplitContainer’ a separar as duas grandes áreas da interface e, à esquerda, um painel que irá ser semelhante – quando preenchido com alguma coisa – ao oferecido pelo outlook.

Usando os excelentes controlos Krypton Toolkit, ainda não fiz código nenhum… mas infelizmente a aplicação ainda não faz nada!

Obter a parte decimal em C#

caxaria — Fri, 04 Jul 2008 14:30:35 +0000

Ao ler o blog do Tiago vi uma solução que ele colocou para encontrar a parte decimal de um número usando C#.

À primeira vista pareceu-me que a solução dele era um pouco ingénua:

public static int GetDecimalPart(double value)
{
    int number = (int) value;
    string numbString = number.ToString();
    int stringLength = numbString.Length;
    return Int32.Parse(value.ToString().Substring(stringLength + 1));
}

Quer dizer, usar strings e Lenght’s? :S Não me parece que seja bom… Então decidi tentar fazer melhor … Esta foi a minha primeira iteração:

public static double GetDecimalPart2(double value)
{
    return value % 1;
}

Ah! Genial, não é? Claro que já tinha um teste unitário à espera:

[Test]
public void CheckSimpleSolution()
{
    Assert.AreEqual(0.02, DecimalTools.GetDecimalPart2(1.02));
}

Infelizmente o resultado não é o esperado:

Mas OK. Aqui o problema é que o double, que estamos a usar no GetDecimalPart2 não tem precisão suficiente para estas operações… Basta então tentar assim:

public static double GetDecimalPart2(double value)
{
    return (double)(((decimal)value) % 1);
}

Basta converter o valor para um decimal que, tendo maior precisão, não perde valores na cálculo do ‘% 1′. Como o número original com que estou a trabalhar é um double no final posso voltar a converter para double, sem ter receio de encontrar uma excepção. Correndo o teste:

Excelente… Mas… vendo o código original… o retorno é um inteiro! Isso quer dizer que o valor de retorno de um argumento de 1.02 seria 2, em vez de 0.02. Mas isso também seria o resultado de 1.2… Tenho de ver:

[Test]
public void CheckOriginalForDuplicateResults()
{
    Assert.AreNotEqual(DecimalTools.GetDecimalPart(1.2), DecimalTools.GetDecimalPart(1.02));
}

Ouch… Ao que parece, enganei-me nos requisitos… Pela implementação do Tiago, vejo que ele quer algo completamente diferente. Vejam a seguinte tabela:

Valor Original	GetDecimalPart	GetDecimalPart2
1.02	2	0.02
1.2	2	0.2
1	0	0.0

Apesar do que se pretendido no GetDecimalPart não me fazer sentido, se isso é mesmo o desejado, não me lembro de nenhuma implementação que seja melhor que a do Tiago…

Agora acho que deviam ir ao site dele dizer quanto admiram o código dele e deixarem aqui uns comentários para me dizerem o quanto me odeiam por vos ter feito perder este tempo todo