De regreso a C++

Hace un par de semanas comencé a trabajar en proyecto con C++. Hacía ya bastante tiempo que estaba con ganas de hacer un proyecto de índole industrial/comercial con C++ por ello cuando me surgió la oportunidad de este proyecto, ni lo dudé a pesar de estar con una agenda casi completa.

El proyecto consiste básicamente en ayudar a un equipo a implementar prácticas técnicas para mejorar la calidad del producto. Dicho producto fue creado hace ya varios años y no cuenta con ningún tipo de pruebas (ni automatizadas ni manuales). El proceso de prueba es totalmente ad-hoc, lo cual implica que dependiendo quien realice la prueba, el resultado puede ser distinto.

Inicialmente pusimos en funcionamiento un servidor de integración continua (Jenkins). Luego revisamos el proceso del desarrollo-testing y propusimos algunos cambios y este momento nos encontramos trabajando en implementar “developer testing”: usando Google Test como framework de testing estamos escribiendo pruebas unitarias y de componentes sobre las partes más sensibles del producto.

Continuará…

 

No more System.IO.File

If you are working with .Net and you need to read/write files you may be familiar with the System.IO.File class which provides many methods to manipulate files. But there is an issue with that class: its methods are static and because of that you won’t be able to mock it*.

After dealing with this situation for several years and using always a very similar strategy, I finally decided to create a reusable component to encapsulate the System.IO.File class.

The component I created is called System.IO.Utilities, its code is available on Github and it is also published on NuGet, ready for you to use it. At this moment it just provides an interface with one implementation that wraps the System.IO.File class.

Here you can see how to use it.

Contributions are welcome 😉

(*to be more precise: you won’t be able to mock that class with proxy-based mocking tool like Moq, but you can still mock it with “lower-level” tool like TypeMock)

Nuevo proyecto: de regreso a .Net

Nuevo proyecto: de regreso a .Net

Hace un par de semanas comencé un nuevo proyecto, esta vez con tecnología .Net y con un contexto interesante:

  • El proyecto es de desarrollo y mantenimiento evolutivo de un sistema existente
  • El sistema está compuesto por un conjunto de aplicaciones de distinto tipo
  • El sistema lleva varios años en producción y no tiene ningún tipo de pruebas automatizadas
  • La documentación funcional y técnica es escasa (prácticamente nula)
  • Varias de las bases de datos no tienen claves foráneas
  • El sistema escala en forma vertical y no horizontal

En este contexto voy estar colaborando en cuestiones de arquitectura, operaciones y prácticas técnicas de desarrollo.

Continuará…

Integrating .Net Build tools: MSBuild, NuGet, FxCop, StyleCop and NUnit

These days it is very common to have a continuous build process that includes: compilation, code analysis and automated tests. The way of implementing this kind of process varies depending on the technology of the project.

I have worked with Ruby, Python, Java, JavaScript, Smalltalk and some other languages and in all cases you just need to install 3 tools:

  • the runtime/sdk (like ruby, jdk, cog)
  • a package manager (like bundle, maven, pip, metacello)
  • a build tool (like rake, maven, fabric)

Any other thing you may need (linter, testing framework, etc), you can get it using the package manager and make it run as part of your build script.

But in .Net the situation is more complex. First of all everything seems to be very tight to Visual Studio (the IDE). Because of this, many people just install the Visual Studio in the build server.

Additionally to this the .Net SDK does not provide a test framework. You can use NUnit (which you will have to install manually) or you can use MSTest but to use it you need to install Visual Studio.

FxCop (the linter) comes with Visual Studio but if you don’t want Visual Studio, then you have to install it manually.

So, in order to avoid several manual tasks when setting up a new dev box and also to minimize any possible difference between dev boxes and the build server box I did the following:

  • I downloaded all the tools I wanted to use in my build process and placed them into the same directory (c:\BuildTools).
  • I wrote a build script (using MSBuild and defining my own targets). This script “glues” the invocation to all of these tools: NuGet, FxCop, StyleCop and NUnit.
  • Finally I package all these stuff in a self-extracting .zip file so all the team members can easily replicate my setup.

In order to have the build process to run continuously I also installed this package in the Jenkins build server.

buildtools-v4buildtools-layout

Análisis de Código en .Net

Al hablar de análisis de código en .Net es necesario diferenciar entre Source Analysis y Code Analysis.

Con Source Analysis nos referimos al análisis del código fuente escrito por el programado (típicamente en C#) el cual se realiza con la herramienta StyleCop.

Con Code Analysis nos referimos al análisis del byte code (MSIL) generado como resultado del proceso de compilación. La herramienta para esto es FxCop.

Ambas herramientas funcionan en base a un conjunto de reglas que pueden personalizarse e incluso extenderse. Si bien estas herramientas trabajan sobre distintos artefactos y tienen distintos objetivos, hay ciertos puntos en los que se superponen. Para entender esto analicemos 3 situaciones “incorrectas”:

  • Una clase escrita en C# nombrada todo en minúsculas, es una situación que seria detectada por StyleCop pero no por FxCop
  • Una clase que oculta un método declarado en una clase base, es una situación que será detectada por FxCop, pero no por StlyeCop
  • Un método con 20 parámetros, es algo que puede ser detectado tanto por StyleCop como por FxCop

Inicialmente ninguna de estas dos herramientas venia integradas con Visual Studio y debian ser descargadas e instaladas por separado. En la actualidad StyleCop continua en esta situación, pero no FxCop, que fue incorporado nativamente a Visual Studio en la versión 2008 (o puede que sea 2010, no estoy seguro).

Continuará…

DDD: implementing object’s identity

One important thing to consider when implementing a domain-driven design is object identity.

In most languages, each object identity is determined by the memory address of the object, but if we are implementing a DDD then we shoud redefine object identity in terms of our domain. For example, let’s suppose we are working in a bank domain, and we have an Accout class, then you should define the identity of Account objects based on the account number.

When working with C#, there are four methods related to the identity of objects, all of them defined in the root class Object:

public virtual bool Equals(object obj);

public static bool Equals(object objA, object objB);

public virtual int GetHashCode();

public static bool ReferenceEquals(object objA, object objB);

Let’s analyze them one by one.

bool Equals(object obj)

By default this method will compare object’s memory address, but that is not correct when implementing a DDD. As mentioned before identity of our domain classes should be define in tern of domain concepts, so we should override this method. Continuing with the Account class example, this method should compare account number: same account number then same object.

public override bool Equals(object obj)

{

Account otherAccount = obj as Account;

if (otherAccount == null)

return false;

return this.Number.Equals(otherAccount.Number);

}

static bool Equals(object objA, object objB)

This method is static and just invokes Equals method of instance objA passing to it the objB as a parameter.

int GetHashCode()

This method is not directly related to object’s identity. It is used when a hash code is needed to represent the object, for example if we want to store the object in a hash-based struture like a hashtable. From msdn: ” The default implementation of the GetHashCode method does not guarantee unique return values for different objects. Furthermore, the .NET Framework does not guarantee the default implementation of the GetHashCode method, and the value it returns will be the same between different versions of the .NET Framework. Consequently, the default implementation of this method must not be used as a unique object identifier for hashing purposes.”

When implementing a DDD we should override this method in our domain classes to return different values for not equal objects. In the Account class example we could use the account number as the hash code.

public override int  GetHashCode()

{

return this.Number;

}

static bool ReferenceEquals(object objA, object objB)

This method simply compares memory addresses, the same behaivour that Equals default implementation.

Well, this is it, I hope this post to clear enough.

If you want to see some tests running to validate this and make your own test you can download my code from here.

In future posts I will write about the relation of this with the equals operator (==) and the importance of equals method when working with persistence frameworks like NHibernate.