Durante este fin de semana tengo previsto cambiar de hosting (de Dreamhost a Silicontower) y de versión de WordPress, así que es posible que ocurran cosas extrañas durante un par de días.

Que la fuerza me acompañe.

Finally I found in the excellent pinvoke.net site a very nice and simple example using a simple call to iphlpapi.dll’s SendARP method. The trick was to use ARP to get the MAC from the IP.

Note that this has it’s limitations, as I will only work if the remote machine is in the same network and the packet does not need to go through a router. I was enough for our needs.

Here’s the code I adapted from the example:

[csharp]
public static string GetMAC(IPAddress ipAddr)
{
var mac = new byte[6];
var len = (uint)mac.Length;

var result = SendARP((int)ipAddr.Address, 0, mac, ref len);

if (result != 0)
{
return “MAC not found!”;
}

var str = new string[(int)len];

for (var i = 0; i < len; i++)
{
str[i] = mac[i].ToString(“x2″);
}

return string.Join(“:”, str);
}

[DllImport("iphlpapi.dll", ExactSpelling = true)]
private static extern int SendARP(int destIP, int srcIP, byte[] pMacAddr, ref uint phyAddrLen);
[/csharp]

Enjoy!

WARN: custom type is not Serializable: MyLibrary.MyCustomDataType

Hace unos días estuve dándole vueltas en el grupo de NHUsers de nuevo al tema de la localización de propiedades usando NHibernate para ver si se me ocurría una forma más potente de hacerlas, dado que el mecanismo que usamos actualmente no permite usar ordenación a través de SQL, por lo que para ordenar los datos por la columna localizable, hay que procesar todas las entidades, lo que es un problema cuando hay muchas.

En resumen, hay 2 modos fundamentales y ampliamente documentados de hacer campos localizables con NHibernate.

Método 1: Serializando la propiedad a través de un IUserType

Esta aproximación es por ejemplo la que describe Fabio Maulo en su blog, usando LocalizablePropertyType del proyecto uNHaddins. Básicamente se trata de almacenar todas las cadenas de traducción en un solo campo y el IUserType se encarga de obtener un diccionario u otra estructura más compleja a partir del valor del campo y de almacenar esa misma estructura en forma de string.

En mi caso, no usé exactamente este tipo porque quería almacenar también un identificador de idioma por defecto y algunas cosas más, pero no es algo complicado de hacer.

Internamente normalmente almacenaremos algún tipo de diccionario con el idioma como clave y el valor la traducción pero es sencillo exponer la propiedad como un string haciendo que el get obtenga el valor correcto para el idioma actual (si es que esta funcionalidad no la implementamos en nuestro propio diccionario).

Ventajas:

• Sencillo de realizar
• No se necesitan tablas adicionales
• Transparente

Inconvenientes:

• Al ser un campo calculado, no permite usar ORDER BY
• La propiedad no puede ser un string

Método 2: Almacenar la propiedad en otras tablas

Hay varios ejemplos de cómo realizar esto, básicamente se trata de mapear la propiedad a una estructura de tipo diccionario donde se almacenan las distintas traducciones del valor de la propiedad indexadas por código de la localización (bien en texto o usando el LCID). Esto se puede hacer más o menos complejo, pero fundamentalmente el principio es el mismo.

Todo esto se suele apoyar en una clase que se encarga de almacenar el diccionario de localizaciones y provee métodos para añadir, eliminar y obtener de forma sencilla dichas cadenas, haciendo uso del Thread.CurrentThread.CurrentCulture para obtener el idioma seleccionado actualmente.

Como no, Ayende ofrece una solución al problema basada en la simplicidad en Localizing NHibernate: Contextual Parameters, usando una fórmula en el mapping para obtener la propiedad Name de la entidad y un filtro en la sesión para que funcione la fórmula. Igual no soluciona los problemas en todos los escenarios, pero es una lectura interesante.

En esta otra propuesta de WebDevBros, Michal nos propone Create a multi languaged domain model with NHibernate and C#. Muy interesante. Por un lado, se crean dos tablas, una con los diferentes diccionarios que corresponderán a las distintas propiedades a localizar, y otra tabla con los valores de cada diccionario, que se mapea con un <map> de forma sencilla. También una clase que sirve para contener las traducciones y facilitar el acceso a las mismas.

En esta misma linea, Siim Viikman muestra en Mapping translations in NHibernate una aproximación muy similar a la anterior que conviene también leer porque aporta otra variante a la solución. Esta quizás no es tan cómoda de usar como la anterior pero puede tener sus ventajas.

En Localizable entities with Nhibernate (Part1, Part2 y Part3), Alkampfer propone una solución algo compleja, que se basa en un objeto que mantiene el idioma actual seleccionado durante el ciclo de vida de la aplicación y en una clase de apoyo que gestiona las traducciones. Es de lectura muy interesante aunque en mi opinión se puede hacer lo mismo evitando el objeto Registry que crea y usando Thread.CurrentThread.CurrentCulture.

Ventajas:

• Uso de todas las posibilidades de la base de datos y SQL

Inconvenientes:

• Mapeo más complejo (dificil en algunos casos o imposible usando Fluent NHibernate)
• Más tablas, más datos

Conclusión

En resumen, las propiedades traducibles o localizables son un problema difícil de resolver que generan una capa de complejidad en el acceso a datos y en la gestión de dichas traducciones. Aun así me puedo aventurar a dar ciertos consejos

• Antes de localizar una propiedad, pensar si realmente es necesario ¿realmente es necesario?
• Si no vamos a necesitar ordenación u indexación por SQL, el método basado en IUserType es más que suficiente y ahorramos problemas. NOTA: Si se quiere indexación, siempre se puede usar Lucene.NET y NHibernate.Search con un Bridge personalizado que almacene todos los idiomas.
• Si necesitamos ordenación, seguramente será solo en algunos campos concretos, así que podemos solamente usar el segundo método en los campos más críticos para simplificar nuestra vida.

En mi caso al final hemos optado por una solución mixta, usando el primer método en la mayoría de los casos y cuando se ha necesitado tener listados grandes ordenados por la propiedad localizable, hemos optado por una solución parecida a la de WebDevBros pero con una tabla por cada campo localizable porque no son muchos y el mapeo es más simple.

El más leido de 2009, NHibernate Burrow and NHibernate Search, explicando la integración de estas dos estupendas librerías. Burrow permite manejar sencillamente las sesiones de NHibernate en entornos web y Search permite integrar con Lucene. También escribí la versión en español del artículo.

Más de NHibernate: NHibernate Validator custom messages, o cómo conseguí personalizar los mensajes del validator mediante extensibilidad de un modo muy sencillo y potente. Supongo que con el tiempo Validator soportará esto nativamente.

Después otro más en inglés, ASP.NET MVC and ReturnUrl, quejándome de que muchos ejemplos de autenticación con MVC no respetan el parámetro ReturnUrl correctamente, lo que es un error a la hora de hacer un mecanismo útil de autenticación.

Y por último, los Principios básicos de OOP: SOLID que siempre deberíamos tener todos presentes a la hora de diseñar una aplicación y mantener la coherencia, la facilidad de uso y la mantenibilidad.

Y dado que este año no he escrito mucho, lo voy a dejar aquí. En 2010, más ASP.NET MVC, más NHibernate y más de todo.

¡Feliz 2010!

El primero es sobre NHibernate y el segundo sobre ASP.NET MVC, dos temas que sigo de cerca porque los uso diariamente en mi trabajo, recogiendo noticias que van apareciendo en los blogs a los que estoy suscrito. Por supuesto hay muchas en inglés porque la mayoría de la información se publica en este idioma aunque intento poner cosas en español también:

• NHibernate Feed
• ASP.NET MVC Feed

Espero que resulten de utilidad.

1. Use the Windows registry – This may be a good solution for desktop applications but depends on the software installed on the machine and typically web servers don’t have Acrobat or Office.
2. Use urlmon.dll’s FindMimeFromData – I don’t know exactly the efectiveness of this method, but it’s used internally by Windows. It should give good and reliable information but you have to read the file and give the method up to 256 bytes of the file header.
3. Use IIS information – Maybe the most obscure mechanism, based on Directory Services and COM stuff. It’s based on the same mechanism IIS uses, so it should be quite reliable, but complex and may not be the fastest.
4. Use your own dictionary – Maybe not the most elegant but even .NET uses this internally (see System.Web.MimeMapping… you know how). You get a bunch of types from somewhere and add them to a dictionary with the associated extension. Easy.

So, the optiones are clear. Finally in my case, I used a simple dictionary to ensure compatibility between platforms and homogeneity. Using other mechanisms could lead to strange errors on some platforms that I wanted to avoid over other benefits. But there are much more elaborate mechanisms that can be done.

Classic ASP.NET has the login form component that puts the same exact URL used to access the login page in the form action URL, preserving the ReturnUrl parameter and then, FormsAuthentication.GetReturnUrl() gets it from the Request.QueryString collection.

Fortunately, the GetReturnUrl() method looks as well in Request.Form in case there’s nothing in the query, this way, we can use a hidden field as well to store the ReturnUrl in the View and pass it through POST when the login form is submitted.

So, in ASP.NET MVC we have two options:

1. Use simply Html.BeginForm() without parameters, which will put a simple form tag, with the same URL as the current one and use POST by default
2. If we want to have more control on the Html.BeginForm(), put a hidden field with the value of the ReturnUrl, only if the ReturnUrl is not empty, or it will fail. This can be obtained from the Request.QueryString collection, the ViewData if we put it previously on the Controller action or even better store it in the ViewModel and have a strong typed reference.

And that’s it. Then, FormsAuthentication.GetReturnUrl() will get the proper URL and other methods like FormsAuthentication.RedirectFromLoginPage() will also work seamlessly.

Aplicado al mundo del desarrollo de software, lo que se conoce como el principio KISS, implica resolver los problemas del modo más sencillo posible y posiblemente ésta sea la mejor solución.

Código
Desde el punto de vista del código tiene más implicaciones a parte de la simplicidad:

• Un código más simple es más sencillo de mantener, lo que ahorrará tiempo en el futuro.
• Además, será más sencillo de comprender por cualquier persona que entre en el equipo de desarrollo.
• Cuesta menos de escribir
• Menos lineas equivalen a menos bugs, lo que significa código de mayor calidad

Gestión de proyectos
Pero todo esto carece de sentido si desde no se tiene también en cuenta desde el nivel de gestión de los proyectos de software. Es estupendo pensar en miles de funcionalidades para un producto pero ¿qué sentido tienen? Primero habrá que hacer lo más simple para luego ir añadiendo más cosas a una base sencilla y comprensible.

Hay que construir software sobre una base sólida y unos requisitos simples y concretos. Esto permitirá desarrollar unas funcionalidades simples y robustas en menos tiempo y una vez el producto tiene cara y ojos, se pueden ver las carencias y se pueden encontrar nuevas posibilidades.

Pensar en cientos de funcionalidades, además tiene otras implicaciones menos obvias:

• Tests de usuario menos frecuentes pero mucho más complejos y largos.
• Bugs más difíciles de encontrar y de solucionar.
• Time-To-Login (tiempo entre que se empieza el desarrollo hasta que se tiene una primera release) mucho más alto.

Muchas de las metodologías ágiles se basan en parte en este principio para desarrollar un software evolutivo en vez de crear gran cantidad de especificaciones y documentos que pueden tardar años en implementarse y meses en integrarse.

En resumen, antes de escribir un método, piensa si no lo estás complicando demasiado y antes de añadir un requisito a una release… piensa si realmente es necesaria en ese momento. Recuerda: KISS.

SRP: Single Responsibility Principle:
El principio de responsabilidad única nos dice que nunca debe haber más de un motivo para que una clase cambie, o lo que es lo mismo, que una clase solamente debe tener un propósito. Esto parece simple pero en realidad es uno de los principios más fáciles de violar y muchas veces no es fácil distinguir las responsabilidades.

OCP: Open-Closed Principle:
El principio abierto/cerrado implica que las clases de software deben estar abiertas para la extensión pero cerradas para la modificación. Este es el principio por el cual se hacen privadas las variables del miembro o que no se usan variables globales. El truco de este principio está en la abstracción. Las clases abstractas implementan un código inalterable desde fuera pero obligan a extender de ellas para usar este código a parte de que se promueve la reusabilidad.

LSP: Liskov Substitution Principle:
El principio de sustitución de Liskov implica que las clases derivadas deberían poder ser sustituidas por sus clases base. Es decir, es en cierto modo una extensión del principio anterior: mientras que OCP promueve la herencia de clases base, LSP promueve que la herencia se haga de forma transparente, es decir, que heredar es bueno pero no hay que olvidar las raíces. Es decir, no implementemos un método en una clase heredada que no esté en la clase base porque romperemos este principio.

De OCP y LSP se deduce que las clases base (abstractas o no) modelan el aspecto general y las clases heredadas modelan el comportamiento local.

DIP: Dependency Inversion Principle:
Básicamente, el principio de inversión de dependencia promueve que hay que depender de abstracciones, no de concreciones. Dicho de forma más compleja, los módulos de más alto nivel no deben depender de los de más bajo nivel sino que ambos deben depender de abstracciones. Y a su vez, las abstracciones no deben depender de los detalles sino al contrario.

En este caso, el uso de interfaces resulta muy beneficioso y un framework de inversión de control (Castle Windsor, StructureMap, por citar algunos) van a hacer que resulte más obvia la necesidad de abstracciones. Además, el testado unitario resulta mucho más sencillo ya que la independencia entre los distintos módulos es muy elevada.

ISP: Interface Segregation Principle:
Este principio de segregación de interfaces indica que no se debe hacer depender las clases de interfaces que no necesitan y que debe haber granularidad en las interfaces para dotar de aspectos específicos a las distintas implementaciones.

En general, en Java y C# se pueden implementar tantos interfaces como se quiera por lo que es sencillo llevar a cabo este principio. Las interfaces son la forma más práctica de modelar las clases y dotarlas de aspectos particulares así como incluso tratarlas de diferente modo según las interfaces implementadas.

Y estos son básicamente los principios SOLID que aunque llevan ya muchos años siguen siendo vigentes y ayudan a desarrollar un código más reusable, mantenible y claro. Además, con las herramientas actuales de refactorización es muy fácil extraer interfaces y clases abstractas de las ya existentes sin tener que revisar cientos de líneas de código. Y cómo no, tener un buen conjunto de tests unitarios ayudará a que cualquier refactorización se haga sin miedo a romper toda la funcionalidad existente.

Referencias: Principles of OOD