Crazy Pointer

Nocturnal Initiative Events (1/2): Introducción

2009-07-06T23:09:00.001+02:00

En la siguiente mini-serie de entradas estudiaremos la implementación de un sistema de Eventos en C++ que ha seguido el código de Nocturnal

Introducción Eventos

En este caso concreto, por evento me refiero a una implementación del patrón Observer:

El patrón Observer define una relación uno-muchos entre objetos, de forma que un objeto (el sujeto, subject) envía una notificación a uno o varios objetos (los observadores, observer) cuando ocurre un cambio de estado en el subject.

Para ello los observers han de registrarse previamente con el subject, para establecer que quieren ser notificados. Con este patrón evitamos que los observers tengan que realizar un pooling periódico para preguntarle al subject si ha cambiado su estado, y a la vez tenemos acceso al estado de los objetos observer, pues el código que se ejecuta cuando ocurre el cambio de estado es parte de los observers.

¿Cómo implementar ésto en C++? Para responder a ésto, antes debemos sentar algunas bases.

Punteros a función

En C/C++ una implementación parcial del patrón observer se consigue con punteros a función. Un puntero a función es una variable que almacena un puntero a la dirección de memoria donde empieza una función, de forma que al llamar a la variable con la sintaxis de una función, se ejecuta aquella a la que apunta

//Punteros a función en C/C++. 

//Puntero a función que recibe un entero como argumento y retorna un std::string
(std::string) (*MyFunctionPointer) ( int entero);

//definimos un par de funciones que cumplen la firma anterior
std::string Funcion1(int integer)
{
	return "null";
}

std::string Funcion2(int integer)
{
	std::ostringstream oss;
	oss << integer;
	return oss.Str();
}

//Declaramos una variable que almacenará el puntero a la función que queramos
MyFunctionPointer variableQueAlmacenaUnPunteroAFuncion;

//asignamos el valor de Function1 al puntero a función
variableQueAlmacenaUnPunteroAFuncion = Funcion1;

//prints "null"
std::cout << variableQueAlmacenaUnPunteroAFuncion (5) << std::endl;

//asignamos el valor de Function2 al puntero a función
variableQueAlmacenaUnPunteroAFuncion = Funcion2;

//prints "5"
std::cout << variableQueAlmacenaUnPunteroAFuncion (5) << std::endl;

Con los punteros a función sólo podemos almacenar una única función. Si quisieramos almacenar un conjunto de funciones, tendríamos que crear una lista de punteros.

Punteros a Método

El problema es que los punteros a función sólo pueden almacenar, bien funciones tradicionales C, o bien métodos estáticos de una clase. Esto sucede porque un método de una clase siempre tiene un parámetro oculto, el puntero this. Por ello en C++ existen los punteros a métodos:

class MiClase
{
	public:
		int MiMetodo(int entero1, int entero2){return entero1 + entero2;}
};

//Puntero a método de la clase MiClase
typedef int (MiClase::*MiPunteroAMetodo) (int entero1, int entero2);

Sin embargo una importante limitación es que para invocar un puntero a método, se requiere una instancia de la clase para la cual se ha definido el puntero a método:

MiPunteroAMetodo variableQueAlmacenaUnPunteroAMetodo = &MiClase::MiMetodo;
MiClase* miClase = new MiClase();
(miClase->*variableQueAlmacenaUnPunteroAMetodo)(5, 5);

Es decir, que necesitarmos guardar tanto la función método, como una instancia del objeto a la hora de implementar eventos en C++

Delegados y Eventos en C#

En C# tenemos la figura del delegate (delegado) que básicamente es lo mismo que un puntero a función y un puntero a miembro, ya que admite funciones y metodos de clase. A su vez permite "de serie", el registrar varias funciones al mismo delegate, de forma que cuando éste es llamado, se ejecutan todas las funciones registradas, y no sólo una como ocurre con los punteros a función o los punteros a método de C/C++ Un evento en C#, no es más que un delegado ya instanciado y con una sintaxis especial. Por ello los eventos en C# son una implementación de libro del patrón observer.

Para la siguiente entrada veremos cual ha sido la aproximación seguida en el código de Nocturnal para implementar eventos en C++.

Contrato NDA simple y sencillo

2009-05-31T13:16:00.000+02:00

Contrato NDA (No Divulges Amigo)
El presente acuerdo se realiza en el día __ de ___ de ____, reunidos_____________ (en adelante "El Consejero") y _____________ (en adelante "El Artífice" o "Yo") sobre el trato de la información (en adelante "La Idea") que El Artífice ha decidido compartir con El Consejero.

Exposición
El Artífice tiene una gran idea que elige compartir a El Consejero, con el conocimiento mutuo de que El Consejero es amigo de El Artífice y no le va a joder.
Posibilidades de jodienda incluyen, sin limitarse a:
1. Adaptar parte o toda La Idea por parte de El Consejero para propósitos propios.

2. El Consejero comparte parte o toda La Idea con otros que no están adheridos a este contrato.
3. El Consejero no ha intentado con todas tus fuerzas proteger La Idea

Esto es un acuerdo de buen rollo, donde al pedir a El Consejero que se adhiera al mismo, se espera que El Artífice consiga dormir con algo de tranquilidad por las noches al introducir un poco más de formalidad a la hora de compartir La Idea. El Artífice cree solemnemente que La Idea sólo podrá mejorar por medio de las opiniones honestas y sinceras de El Consejero.

Alcance
Los términos de este acuerdo continuarán hasta que La Idea no sea considerada confidencial por El Artífice.

Ruptura de los términos
Este acuerdo no tiene un ápice de base legal. Sin embargo, en caso de cualquier ruptura o violación del acuerdo, El Artífice será libre de realizar todas o parte de las siguientes acciones, sin limitarse exclusivamente a ellas:
1. Maldecir a El Consejero y posiblemente mentar a la Madre que lo Parió, o cualquier otro familiar cercano.

2. Contarle a todo el mundo la manera en que el Consejero le ha jodido.
3. Escribir al respecto de la traición de El Consejero en el blog de El Artífice, y con MAYÚSCULAS.
4. Dejar de considerar a El Consejero como una persona en la que se le puede confiar a la hora de compartir información.

Compartir
El Consejero podrá compartir parte o toda La Idea con terceros, siempre que El Artífice sea previamente notificado y que dichos terceros se adhieran a los términos y principios de este acuerdo NDA.

Cancelación
La cancelación de este contrato puede realizarse unilateralmente por cualquiera de sus participantes, pero El Artífice espera que El Consejero no se comporte como un capullo.

Comprendes y aceptas los términos de este acuerdo al leerlo. Si encuentras parte de este acuerdo incómodo o confuso, tampoco te preocupes mucho. Podemos hablar de otro tema.

Traducción libre de http://www.friendda.org/

Gamelab 2009 inscripción abierta

2009-05-15T01:00:00.001+02:00

La Feria Internacional del Ocio Interactivo, es decir, el Gamelab 2009 ya admite inscripciones, y hacerlo es tan sencillo como registrarse en un formulario. Entre otras novedades este año el acceso es gratuito, lo que es de agradecer. Además el evento cambia de lugar, celebrándose esta vez en la Universidad Laboral de Gijón, los días 1, 2 y 3 de Julio.

Este año, además de los “tradicionales” Premios a la industria del videojuego, hay un evento muy interesante, el Gamelab Challenge.

El Gamelab Challenge es una competición para que un equipo de máximo 4 personas cree un juego en ~~48 horas~~ dos días.

Es interesante que el código de los proyectos se publicará con licencia libre, aunque la propiedad intelectual seguirá perteneciendo a los participantes.

Seguro que se verán cosas muy interesantes, talento no falta. Además, si te inscribes además te pagan el alojamiento. :)

Podéis estar al tanto de las últimas novedades por medio del twitter del Gamelab, ver las fotos del evento que se irán publicando en Flickr, así como asistir virtualmente a las conferencias por medio del canal de youtube.

Nuevo dominio para el blog

2009-04-29T00:14:00.000+02:00

Una corta entrada para estrenar el nuevo dominio del blog: http://www.crazypointer.com aprovechando el alta en Google Apps
Ahora a sacarle partido e intentar meter más de una entrada al mes :)

Cómo usar el DNI electrónico (2/2)

2009-04-26T19:24:00.001+02:00

Ya ha pasado casi un mes desde la anterior entrada, así que creo que ya va siendo hora de finalizar con esta mini-serie y ponernos a instalar y configurar el hardware y software necesario para poder utilizar nuestro DNI-e.

El lector

Lo primero que necesitamos es configurar el lector en nuestro sistema. Obviamente esto dependerá por un lado del sistema en cuestión y por el otro del modelo del lector escogido. En mi caso el lector tiene el aburrido nombre de LTC31, que contrata con el curioso nombre de su fabricante, una empresa española denominada C3PO que no se cómo habrá pasado desapercibida a atenta mirada de George Lucas y sus abogados. La elección del mismo ha sido simple: bajo precio y disponibilidad en la tienda más cercana a mi casa.

La configuración del lector no es complicada. En la página de soporte del fabricante instalamos los drivers para que el sistema lo reconozca, conectamos el lector a un puerto USB y localizará los drivers automáticamente. Me encontré con una sorpresa en el caso de Mac, donde el lector no necesita instalación de driver alguna, ya que el lector sigue el estándar USB CCID (la norma USB para lectores de smart-cards, que es lo que es en el fondo un lector de DNIe) y funciona perfectamente con los drivers del sistema sin instalar nada. Mola.

Módulos criptográficos

Ahora toca instalar este software de genérica denominación. Permitiéndome un poco de deformación profesional -y para reflejar que de verdad he mirado un poco este tema- comentar que un módulo criptográfico no es más que una norma que define un API que permita comunicarse con dispositivos criptográficos, que en nuestro caso es el lector.

Hay dos implementaciones, una para windows, denominada CAPI y otra para Mac y Linux, llamada PKCS11. Ambas pueden obtenerse desde el portal oficial para el DNI-e, en la sección de descargas.

Con esto ya está casi todo preparado. Sin embargo hay un problema. Como explicamos en la primera entrada sobre el DNI-e, en el proceso de crear una comunicación segura entre ambos usuarios tenemos que poder identificar a ambas partes. Nosotros nos identificaremos usando el certificado de autenticación contenido en el DNI-e. El que nos presta un servicio necesitará validarse también usando un certificado que será contrastado con una Autoridad Validadora que será la encargada de verificar que los certificados de dicho servicio son válidos.

Por esto hay que realizar un par de pasos. Lo primero informar al sistema qué Autoridades Validadoras tendremos que usar para comprobar que esos certificados son válidos. Lo segundo es obtener los certificados de los prestadores de servicios.

Instalar Autoridades Validadoras en eL sistema.

Esto también está disponible en el portal del DNIe. Esa página nos muestra los tres principales servicios de validación, que serán la Fábrica nacional de moneda y timbre, el Ministerio de Administraciones Públicas, y el Ministerio de Industria Turismo y Comercio. Para cada uno de ellos tenemos disponible un link de descarga de su certificado (en ficheros .zip que contienen el fichero de certificado .cer)

Debemos descargar los tres y guardarlos en alguna carpeta para instalarlos en el sistema y que sean reconocidos por nuestro navegador.

Internet Explorer

Instalar el certificado no puede ser más fácil. Doble clic en el fichero de certificado y aparecerá una ventana como la que muestro un poco más abajo. Pulsáis el botón “Instalar certificado” y a seguir el asistente. La única duda puede aparecer cuando pregunte por el almacén de certificados donde debería instalarse. Basta con dejar la opción por defecto, que le indica al sistema que lo seleccione automáticamente.

Podremos comprobar que los certificados están correctamente instalados iniciando Internet Explorer, y pulsando en el menú Herramientas / Opciones de internet, pestaña Contenido, botón Certificados.

Firefox

En firefox el proceso es un poco más largo, ya que no obtiene los certificados instalados en el sistema, y deberemos indicarle cuales usar. Sigue siendo muy sencillo en cualquier caso.

Vamos al menú Herramientas / Opciones, y pulsamos en la pestaña Avanzadas en la ventana que aparece, para obtener esto:

Pulsamos el botón Ver certificados. En la ventana que aparece pulsamos la pestaña “Servidores”, y una vez seleccionada esta pulsaremos el botón Importar. Ahora buscamos y seleccionamos los ficheros de certificado que hemos descargado del portal del DNIe (hay que hacerlo uno por uno) y pulsamos abrir. Con eso ya tendremos instalados los certificados, y deberíamos obtener algo parecido a esto:

Comprobando que todo funciona

Ahora ya estamos listos para probar el DNIe desde la página de prueba que nos proporciona el portal del DNIe. Recuerda que antes de hacer click deberás tener el DNIe insertado en el lector. También al hacer clic el sistema nos pedirá el PIN del DNIe por medio de una de estas dos ventanas, dependiendo del navegador que uses:

Clic para probar tu DNIe

Si puedes ver tus datos es que tu DNIe funciona correctamente.

No te olvides de probar también la firma en esa misma página. En el cuadro de texto pones cualquier palabra y pulsas el botón firmar. Te volverá a pedir tu PIN del DNIe, y si todo ha sido correcto debería crear una firma válida.

Si todos los pasos han sido correctos ya podrás acceder a las ventajas del mismo desde las páginas oficiales del estado, a la falta de obtener los…

Certificados de prestadores de servicios

Los prestadores de servicios utilizan certificados para identificarse, igual que nosotros con el DNIe, como hemos explicado. Sin embargo nosotros no hemos instalado esos certificados en el sistema. Lo que hemos instalado son unas herramientas que nos permitirán validar que esos certificados son correctos y que podemos confiar en ellos. Sin embargo podemos encontrarnos con certificados que no usan uno de esas tres Autoridades Validadoras para certificar su validez, pero dándose el caso de que nosotros confiemos en ellas igualmente. Eso nos puede hacer saltar una alerta de seguridad en el navegador, y es posible que nos pille con la guardia baja sin saber qué es lo que pasa o qué hacer.

Hum, explicando esto me estoy haciendo un lío yo mismo, lo que es bastante triste, así que expliquémoslo de otra manera:

Imaginemos que tenemos un amigo, Pepín, que es un fiera en esto del networking y tiene una base de datos que ríete tú de la lista de amigos de Obama en Facebook. El tío además tiene todos los datos posibles de sus contactos: nombre, apellidos, residencia, DNI, una foto, la huella dactilar, su firma manuscrita, sus datos bancarios, edad, altura, peso, el número que calza (de pie)… vamos todo lo que puedas averiguar de una persona, Pepín lo tiene. Sin embargo Pepín es una persona íntegra, que nunca da esos datos a terceros, por tanto se ha ganado la confianza de todos sus contactos y todo el mundo confía en su honradez y principios. Los servicios que ofrece Pepín se basan en esa confianza: tú le das los datos que una supuesta persona te ha dado y el te indica si esos datos son correctos, y además lo hace gratis porque es todo un filántropo. Pepín es por tanto nuestra Autoridad Certificadora.

Supongamos que conocemos a una persona, Juan, que nos da unos datos personales de referencia para certificar su identidad. Como queremos hacer negocios con él y nos hemos llevado malas experiencias anteriores, nuestras alarmas saltan: hemos de asegurarnos de que Juan es realmente Juan, y no otra persona haciéndose pasar por él. Por ello enviamos esos datos a Pepín, y el nos contesta diciéndonos que son correctos. Como quiera que confiamos en Pepín, ahora tenemos la certeza de que Juan es quien dice ser. Juan hace lo mismo con los datos que nosotros le hemos proporcionado para probar nuestra identidad, y todos contentos.

Sin embargo imaginemos que Juan es un tío asocial, que no está en la red de contactos de Pepín, pero que nosotros conocemos de toda la vida. Pues aunque Pepín no pueda certificar que Juan es quien dice ser, nosotros haremos una excepción al procedimiento y simplemente confiaremos en los datos que nos ha proporcionado.

Pues algo parecido pasa cuando queremos acceder a los servicios y usamos nuestro DNIe. El DNIe contiene un certificado digital que nos identifica, y el prestador de servicios tiene el suyo. Ese certificado digital hemos de obtenerlo de alguna parte. Como esto es internet, el futuro y todo eso,la obtención del certificado es automática, y el prestador de servicios nos lo enviará automáticamente en el proceso de crear una conexión segura. Sin embargo si no fuera posible validar ese certificado con las Autoridades instaladas anteriormente, es posible que una alarma de seguridad nos aparezca dependiendo de nuestro nivel de seguridad del navegador, ya que estamos obteniendo un certificado automáticamente que a priori no sabemos de quién es. Sin embargo puede que no nos importe porque confiamos en que esa página web es quien dice ser.

Lo más probable es que nos salte en firefox antes que en IE (sorpresa!), y sea una ventana como esta:

Si sabemos que la página a la que accedemos es correcta en general podremos añadir la excepción de seguridad (que lo que hace es descargar el certificado y añadirlo a la lista de certificados seguros) sin problema.

En este caso la página que hace saltar esa identificación es la del INEM.

Y eso es todo, a partir de ahora podremos utilizar los servicios del DNIe, y con suerte evitarnos tiempo perdido haciendo cola en las administraciones públicas.

No olvidéis visitar la página de vuestro ayuntamiento ya que muchas competencias relativos a estos servicios están descentralizadas y es responsabilidad de cada región proporcionarlas. Por ejemplo, datos de empadronamiento o catastro son datos que deben ser solicitados a tu ayuntamiento.

Feliz uso del DNIe!

Cómo usar el DNI electrónico (1/2)

2009-03-28T02:00:00.006+01:00

Aunque esto no tiene que ver totalmente con la temática del blog considero que es interesante igualmente, así que vamos a hablar del relativamente reciente DNIe, cómo prepararnos para usarlo y ver qué ventajas nos aporta. Lo dividiré en dos entradas para que no me ocupen mucho. Esta será teórica, para comprender grosso modo qué es el DNIe y cómo funciona. La segunda entrada cubre la instalación y configuración de un lector y los navegadores para poder usar el DNIe, y está disponible aquí.

Introducción

El DNIe tiene la misma función que el DNI tradicional, servir como documento acreditativo de la identidad del titular. La novedad es que ahora lo podremos utilizar para acreditar nuestra identidad en el mundo digital, por medio de un certificado digital.

Esto nos permitirá, entre otras cosas, acceder a servicios o realizar trámites con la Administración pública desde casa, evitando desplazamientos y esperas, o la firma digital de documentos, emails, etc, que adquieren la misma validez legal que una firma manuscrita.

Toda la información del DNIe está disponible en su portal oficial.

Características del DNIe

El nuevo DNI tiene el tamaño de cualquier tarjeta de crédito actual, y contiene los datos identificativos de siempre. La novedad es el nuevo chip que incorpora que contiene la siguiente información, copiada vilmente del portal oficial:

Un certificado digital para autenticar la identidad del ciudadano.
Un certificado digital para firmar digitalmente, con la misma validez jurídica que la firma manuscrita.
Certificado de la Autoridad de Certificación emisora.
Claves –pública y privada- para la firma digital.
La plantilla biométrica de la impresión dactilar.
La fotografía digitalizada del ciudadano.
La imagen digitalizada de la firma manuscrita.
Datos de la filiación del ciudadano, correspondientes con el contenido personalizado en la tarjeta.

Funcionamiento del DNIe

Para conocer mejor el funcionamiento del DNIe, hay que dejar claros algunos conceptos. (Los números en paréntesis referencian las características enumeradas anteriormente)

Autoridad Certificadora (AC)

Es la autoridad encargada de emitir certificados digitales.

En el caso de los certificados de Autenticación(1) y Firma(2) incluidos en el DNIe, sólo la Dirección General de la Policía y la Guardia Civil tiene la potestad de emitirlos. Es decir, que son los únicos que pueden crear un DNIe.

No hay que olvidar que existen otras entidades que también pueden emitir otros certificados al margen de los incluidos en el DNIe que también son válidos para trámites telemáticos en España, como la Fábrica de Moneda y Timbre, por ejemplo.

Los certificados son únicos para cada individuo y se generan en el momento en que te entregan el DNIe, un proceso largo por cierto. Si no te gustan los silencios incómodos, tus habilidades de hablar de temas triviales se pondrán al límite cuando estés enfrente del funcionario y tengas que esperar a que estos se creen...

Los certificados se encuentran guardados en el chip del DNIe y sólo se puede acceder a ellos por medio de un PIN (que debería llamarse password) ya que no es un número sino una secuencia de caracteres. Éste se entrega junto al DNIe en un sobre cerrado y es necesario para realizar cualquier consulta de la información que contiene el DNIe, desde los personales (8), hasta los certificados. Dicho de otro modo, cada vez que quieras consultar los datos de tu DNIe o realizar algún tipo de operación con él, deberás introducir el PIN.

Por cierto, si introduces tres veces consecutivas el PIN, el DNIe se bloquea, y deberás ir a un Punto de Actualización del DNIe -que debería estar disponible donde te lo entregaron- para poder desbloquearlo usando la huella dactilar. Cabe destacar que la plantilla biométrica de la huella dactilar (8) no puede ser consultada, sino que es el propio DNIe el encargado de validar una plantilla que se le proporcione de forma externa (es decir, la plantilla leída desde el lector del puesto) con la que el propio DNIe guarda, y aceptarla como válida o no.

Autoridad Validadora (AV)

Estas entidades validan que un certificados emitido es vigente, por ejemplo, que realmente está generado por la Autoridad Certificadora indicada, o que bien este certificado no ha expirado.

Para nuestro caso las autoridades validadoras más importantes serán la Fábrica Nacional de Moneda y Timbre, que presta servicios de validación de forma universal (ciudadanos, empresas y Admon. Pública), el Ministerio de Administraciones Públicas, que presta los servicios de validación a la Administración, y el Ministerio de Industria, Turismo y Comercio, que los presta a empresas, por ejemplo para generar facturas electrónicas firmadas digitalmente.

Firma electrónica

La firma electrónica se realiza utilizando criptografía de clave asimétrica. Resumiendo mucho el procedimiento, esta técnica se basa en el uso de de dos claves relacionadas, de forma que están vinculadas entre si de forma única.

Clave privada: como su nombre indica es personal e intransferible, Con ella efectuaremos la firma de un documento y en ese momento será como si hubiéramos firmado éste de forma manuscrita. Por eso es importante que esta clave privada permanezca en secreto, ya que si alguien más la tuviera podría firmar documentos con nuestra identidad.
Clave pública: esta clave ha de distribuirse a los destinatarios de los documentos y servirá para comprobar que el documento pertenece realmente a la persona que lo firmó con su clave privada. Cada clave pública está vinculada a una, y sólo a una, clave privada.

Se puede establecer una analogía simple pensado en una caja fuerte con dos tipos de llaves. Una de ellas, la llave privada, permite a su usuario abrir la caja fuerte e introducir algo, y además tiene la particularidad de que sólo existe una copia. Por el contrario de la otra llave, la llave pública, tenemos un montón de copias que repartimos entre conocidos, pero ésta sólo permite recuperar lo que hay dentro de la caja, sin posibilidad de introducir algo -supongamos que la sofisticada caja fuerte simplemente expulsa el contenido como si fuera una máquina expendedora. Sí sólo existe una llave privada y nos pertenece, cualquier persona que tenga una llave pública tendrá la certeza de que lo que se encuentre dentro de ella sólo ha podido ser introducido por el propietario de la llave privada.

Una vez dejado claras estos términos, se puede explicar cómo funciona todo esto para poder asegurar nuestra identidad. Bien, supongamos que tenemos un cliente (nosotros), y una entidad que proporciona un servicio que necesitamos pero que para proporcionarlo es necesario estar completamente seguros de que la persona que lo solicita es quien dice ser (*). El procedimiento sería el siguiente:

Utilizando una conexión segura SSL para conectarnos a la web de la entidad (la forma más fácil de identificarlo es porque la dirección de la página web comienza por https, en vez del habitual http) y solicitamos una conexión con autenticación.
La entidad crea un mensaje autenticado por medio de un certificado y nos lo envía. Utilizando una Autoridad Validadora nos aseguramos de que el certificado es válido.
El servicio nos envía un mensaje de inicio de sesión cifrado que procederemos a descifrar por medio de la clave pública incluida en el certificado.
Una vez validado el mensaje de inicio de sesión en el paso anterior, utilizamos nuestra clave privada del DNIe para cifrar un mensaje de establecimiento de sesión, y enviarlo junto a nuestro certificado de autenticación. Como en este momento tenemos que acceder a los datos del DNIe, este debe estar insertado en el lector y nos pedirá el PIN.
La entidad verifica que el mensaje de establecimiento de sesión es correcto desencriptándolo con la clave pública, y se asegura de que nuestro certificado de autenticación es válido.
Como hemos verificado que ambos (cliente y entidad) somos quien decimos ser, se establece la conexión segura y autenticada. A partir de este momento podemos acceder a los servicios.

Servicios Disponibles con el DNIe

Aquí no me voy a complicar de forma exagerada y sólo comentaré algunos servicios que me han parecido interesantes. Para la lista completa (y larga) os remito al listado del portal oficial.

Solicitar la prestación por desempleo, o consulta de la situación personal de prestación por desempleo.

La Agencia tributaria nos permite hacer la declaración de la renta o pagar nuestros impuestos sin esperar colas ni perder tiempo.

Correos nos proporciona una dirección de correo electrónico segura de forma gratuita

También hay una lista de entidades privadas (bancos y una aseguradoras concretamente) que utilizan el DNIe para algunos trámites.

Algunos ayuntamientos proporcionan servicios más concretos. En mi caso tengo suerte y el ayuntamiento de Gijón es uno de ellos. Aunque no he conseguido que funcione con el DNIe :(

En la próxima entrada veremos cómo instalar todo lo necesario para utilizar el DNIe en Windows y Mac con Firefox e Internet Explorer.

Nocturnal Initiative: Smart Pointer (II)

2009-03-24T21:50:00.013+01:00

Ya ha pasado mucho tiempo desde la última entrada, y ya no te quiero ni contar desde la entrada que precede a esta. Llevo sin escribir en el blog por mezcla de mi dejadez aderezado con ciertos cambios en mi vida laboral. Así que retomo la escritura para completar esta mini-serie iniciada ya hace casi un año, algo que no tiene excusa alguna porque lo que quedaba por explicar era muy sencillo.

Recapitulemos, en nocturnal teníamos un interface IRefCount que definía tres operaciones para contar las referencias a un objeto:

IncrRefCount() Incrementa en uno el contador de referencias.
DecrRefCount() Decrementa en uno el contador de referencias.
GetRefCount() Devuelve el número de referencias del objeto.

A su vez teníamos disponible las clases RefCountBase y RefCountAggregator, que implementan dicho interface.

Pues ahora hablaremos de la clase SmartPtr<T> una clase que tiene como fin comportarse exactamente igual que un puntero, pero gestionando automáticamente el ciclo de vida de un objeto según el número de referencias que tenga. Esto significa que, dada una instancia de un objeto en memoria, este se borrará automáticamente cuando ningún otro SmartPtr lo referencie.

Todo esto funciona siempre que T sea un tipo que implementa IRefCount, por tanto utilizará los tres métodos definidos en dicho interface para gestionar las cuenta de las referencias. Si no es así el código ni compilará. Y aunque no es obligatorio para que el código compile, si que es necesario para que todo funcione que sólo utilizaremos un tipo de puntero SmartPtr para gestionar los objetos: si mezclamos punteros “tradicionales” con smart pointers armaremos un cisco épico con toda probabilidad.

Por supuesto que implemente IRefCount es sólo parte del trabajo, ya que un interface por si sólo no incluye el código necesario para gestionar las referencias. Por ello, y suponiendo que no queremos reinventar la rueda, lo mejor será que cualquier objeto que pretendamos utilizar con un SmartPtr derive de RefCountBase, con lo que en la práctica se convertirá en la clase base de toda nuestra jerarquía de objetos.

Pero ¿cómo funciona SmartPtr internamente? Pues haciendo uso tanto de conversiones implícitas en los constructores como de sobrecarga de operadores para simular el comportamiento de un puntero a la par que actualizas la cuenta de referencias.

El contador de referencias se inicializa a 1 al asignar por primera vez un puntero válido a un SmartPtr, y se va actualizando con cada operación de asignación –decrementando la referencia del SmartPtr sobreescrito e incrementando la del asignado, o cuando el objeto SmartPtr es destruido, momento en el que decrementamos en uno el contador de referencias.

Menudo lío, veamos algo de código:

Empezamos con una clase sencilla de prueba

//Clase simple que deriva de BaseRefCount para
//implementar el contador de referencias
class MyClass : BaseRefCount {};

Creamos un par de SmartPtr que apuntan a instancias diferentes de MyClass

//ptr2MyClass1: Contador de referencia a 1
//apunta a la instancia 1 de MyClass
SmartPtr< MyClass > ptr2MyClass1 = new MyClass();
//ptr2MyClass2: Contador de referencia a 1
//apunta a la instancia 2 de MyClass
SmartPtr< MyClass > ptr2MyClass2 = new MyClass();

Ahora mismo ptr2MyClass1 != ptr2MyClass2 ya que apuntan a instancias de objetos distintas.

Sin embargo con una "simple" asignación vamos a ver que ocurren varias cosas:

ptr2MyClass2 = ptr2MyClass1;

ptr2MyClass2 está siendo sobreescrito, con lo que decrementamos su contador de referencias. Como era 1, ahora pasa a ser 0, por tanto como ningún puntero referencia la instancia, hemos de borrar dicha instancia, y así lo hacemos, o mejor dicho, así se hace automáticamente. Por otro lado al asignarle el puntero ptr2MyClass1, lo que estamos estamos diciendo es que ptr2MyClass2 apunte a la misma instancia que ptr2MyClass1, que es la instancia 1 Eso implica que ahora tenemos DOS referencias a la misma instancia, por lo que incrementamos el contador de referencia que pasa a ser 2.

Ahora mismo ptr2MyClass1 == ptr2MyClass2: ambos apuntan a la misma instancia en memoria. Vamos a asignar un puntero nulo:

ptr2MyClass2 = 0;

Como estamos asignando una referencia nula, lo que haremos será decrementar el contador de referencias, con lo que pasa a ser 1.

Por último, imaginemos que ptr2MyClass1, que es el único SmartPtr que apunta a la instancia 1 sale del ámbito actual en el que ha sido declarado, algo como esto:

{
    SmartPtr< MyClass > ptr2MyClass1 = new MyClass();
} 
//Aquí salimos de ámbito, por lo que llamamos al 
//destructor definido para ptr2MyClass1

Pues bien, como al salir de ámbito su destructor es invocado el contador de referencias es decrementado de nuevo. Como éste era 1, pasa a ser 0, y por tanto la instancia es borrada automáticamente.

Como vemos estamos trabajando con punteros sin necesidad de gestionar la memoria y sin crear fugas de memoria.

Pero mucho ojo, ¡porque esto no es válido para semánticas de punteros como arrays!

Por ejemplo este código compila, pero genera fugas de memoria:

SmartPtr< MyClass >* myClassArray = new SmartPtr< MyClass > [2];
myClassArray[0] = new MyClass();
myClassArray[1] = new MyClass();

Eso es debido a que al destruir el puntero myClassArray, no iteramos por cada uno de sus elementos para destruir los objetos que almacena. En estos casos lo más cómodo es utilizar la clase vector de stl, que al destruir un vector si llama al destructor de cada uno de los elementos que almacena:

vector< SmartPtr > myClassArray = vector< SmartPtr< MyClass > > (2);
myClassArray[0] = new MyClass();
myClassArray[1] = new MyClass();

Y ya tenemos arrays que almacenan punteros sin fugas de memoria y auto-gestionados

Como nota final, en la última versión del NocturnalFramework, que ya salió hace algún tiempo la clases necesarias para utilizar SmartPtr se encuentran en el directorio Common/Memory. Si queréis trastear con ella tened en cuenta que hay referencias a ficheros que se encuentran dentro del directorio Common, por lo que lo más cómodo es copiar la carpeta Common completa a vuestro proyecto.

Mono 2.2 released!

2009-01-21T23:00:00.001+01:00

Hace una semana que se lanzó la versión 2.2 de Mono, ¡y yo sin enterarme!.

Viene cargadita de novedades:

Nuevo generador de código IL, más eficiente, que mejora el rendimiento y reduce la cantidad de código IL final.
Reescritura de los PerformanceCounters, que permiten monitorizar el propio runtime. (link a la clase PerformanceCounter en MSDN) También incluye una nueva herramienta visual para este menester.
Soporte SIMD ya incluido en la release (antes estaba disponible en el repositorio)
Soporte para compilación Ahead of Time. Además se puede precompilar todo el código (e.g. para sistemas embebidos) o dejar al compilador que precompile de forma optimizada sólo las partes que te proporcionarán mayor beneficio.

Y las novedades incorporadas específicamente al lenguaje C# son:

Compilador de C# como servicio. Adelantándose a C# 4.0, podrás ejecutar de forma dinámica scripts de C# en tu aplicación, o dicho de otro modo, podrás compilar código C#^desde tu programa ^_^
Gracias al punto anterior, ahora hay disponibles shells interactivas para C#, al estilo de lenguajes como Python o Ruby

Por lo demás son ligeras optimizaciones, corrección de bugs (casi 200 en Windows.Forms desde la versión 2.0) y cosas por el estilo.

Impresionante trabajo el de los chicos de Mono. Go Mono!

Automatizando el proceso de build de tu proyecto (2/n)

2009-01-20T23:39:00.001+01:00

Development tRee

Seguimos con las series dedicadas a automatizar el proceso de build para nuestros proyectos.

En esta entrada definiremos un development tree a utilizar en nuestro proyecto. Esto no es más que un nombre sofisticado para denominar una estructura de organización para todos los ficheros que forman nuestros proyectos, ya sean ficheros de código, recursos, scripts, etc.

Esta no sólo persigue la organización de los ficheros, sino que es básico que tengamos una estructura "estandar" para poder referenciar los diferentes elementos de cara a construir un script que podamos reutilizar. Entrecomillo estándar porque obviamente no hay unas reglas categóricas para estructurar nuestros proyectos: es algo que depende de nuestros gustos y necesidades.

La estructura de directorios (representados por \) y los ficheros (representados por ->) que tengo definida actualmente es la siguiente.

base
	|- \tools
	|
	|- \builds
	|	-> <MainProjectName>.<builddate>.zip
	|				|-\output
	|				|-\reports
	|				|-\documentation
	|	-> ...
	|
	|- \libs
	|
	|- \projects
	|	|- \<VisualStudioProject1>
	|	|	|- \Properties
	|	|		-> guid.txt
	|	|		-> version.txt
	|	|		-> publickey.snk
	|	|- \<VisualStudioProject2>
	|	|	|- \Properties
	|	|		-> guid.txt
	|	|		-> version.txt
	|	|		-> publickey.snk
	|	|- ...
	|	|
	|	|- \<VisualStudioProjectN>
	|	|	|- \Properties
	|	|		-> guid.txt
	|	|		-> version.txt
	|	|		-> publickey.snk
	|	|- \tests
	|		|- \unit
	|		|- \ui
	|		|- \ ...
	|
	|- \resources
		|- \icons
		|- \images
		|- \sounds
		|- ...

La idea es que la estructura completa desde el directorio root va al repositorio de código, de forma que al hacer un checkout obtengamos todo lo necesario para generar el proyecto, aunque eso implique que tendremos datos repetidos entre diferentes proyectos.

root: Aquí va el fichero de build para NAnt y algunos más que servirán para definir
tools: En este directorio van los binarios necesarios para el proceso de build: NAnt, NUnit, etc.
builds: Aquí se generará las última build del proyecto. Contendrá un fichero zip con el proyecto listo para ejecutar y opcionalmente unos informes con los resultados de las pruebas y la documentación.
libs: Todas las librerías externas necesarias para generar el proyecto van aquí. Pueden organizarse también en subdirectorios si es necesario
projects: Aquí van todos los ficheros de código necesarios para generar el proyecto. En mi caso sólo tengo en este directorio el fichero de solución de visual studio. El resto de proyectos va cada uno en un subcarpetas:
- <VisualStudioProjectN> Contiene el código y el fichero de proyecto de Visual studio para generar un assembly (librería o ejecutable). En la subcarpeta Properties tenemos además tres ficheros necesarios para generar siempre un assembly firmado:
  - guid.txt: contiene un número Guid asociado al proyecto
  - publickey.snk: clave pública para fir
  - version.txt: contiene un número de versión para el ensamblado en formato Major.Minor.Build.Revision.
- tests: Aquí van todos los proyectos de visual studio con los assemblies de tests que utilicemos en el proyecto, también organizados en subcarpetas si es necesario.
resources: Resto de ficheros que pertenecen al proyecto: imágenes con logos, sonidos, etc.

Por supuesto aquí hay bastante margen para añadir cosas: scripts para generar bases de datos, ficheros de localización, etc. La idea principal a transmitir es que una vez definida una estructura que nos sirva, podemos automatizar el proceso de generación en base a dicha estructura. Por ejemplo podemos crear un target para NAnt que compile todo fichero .csproj encontrado en projects/tests, y luego utilizando esos resultados, ejecutar nunit desde la consola de comandos para generar un informe que nos indique el estado de los tests.

En mi proceso, además, he definido propiedades para cada uno de los directorios principales de la estructura, de forma que sea más cómodo utilizarlo en los scripts. Por ejemplo, para acceder al directorio root se define la propiedad ${dir.root}. Para acceder al directorio de proyectos, utilizo ${dir.projects}. Para ser consistente en realidad ésta última debería ser ${dir.root.projects}, pero hace que las propiedades aumenten su tamaño, y decidí optar por eliminarlo. Las propiedades se definirían:

<properties>
	<!-- DO NOT DELETE ANY PROPERTY DEFINED IN THIS FILE -->	
	
	<property 
		name="dir.root" 
		value="${project::get-base-directory()}" />
	
	<property 
		name="dir.tools" 
		value="${dir.root}/tools" />
	
	<property 
		name="dir.resources"
		value="${dir.root}/resources" />

	<property 
		name="dir.builds"
		value="${dir.root}/builds" />		
				
	<property 
		name="dir.libs"
		value="${dir.root}/libs" />
				
	<property 
		name="dir.projects" 
		value="${dir.root}/projects" />		
		
	<property 
		name="dir.tests" 
		value="${dir.projects}/tests" />		

	<property 
		name="dir.tests.unit" 
		value="${dir.tests}/unit" />	

			
	<property
		name="dir.projects.temp"
		value="${dir.projects}/tmp" />	
	
	<property
		name="dir.projects.temp.output"
		value="${dir.projects.temp}/output" />	

	<property
		name="dir.projects.temp.reports"
		value="${dir.projects.temp}/reports" />	

	<property
		name="dir.projects.temp.docs"
		value="${dir.projects.temp}/docs" />					
</properties>

Y eso es todo por hoy! Cualquier comentario o sugerencia sobre la estructura elegida será -como siempre- bien recibida.

Automatizando el proceso de build de tu proyecto 1

Post-mortem: Ratchet & Clank

2009-01-02T13:47:00.001+01:00

Aquí tenéis un link al interesante post-mortem del juego Ratchet & Clank:Tools of Destruction (Ratchet & Clank: Armados hasta los dientes en español) de Insomniac, proporcionado por Gamasutra.
A destacar el sistema para el desarrollo de proyectos que usan, dos proyectos simultáneos en diferentes fases: mientras el grueso del equipo se encuentra inmerso en la producción del título actual, otro grupo más reducido ya está metido de lleno en la preproducción del siguiente, solapando ambas fases en el tiempo.

Durante la preproducción se crea un prototipo funcional del juego, lo que les permite descubrir los posibles problemas técnicos que tendrán que afrontar, así como los cambios necesarios del gameplay. Todo el conocimiento obtenido en esa fase se utiliza para establecer el diseño final del juego para finalmente pasar a producción.

También es de destacar su intento por seguir un sistema de desarrollo ágil de forma que intentan obtener versiones funcionales del juego, que mejoran en posteriores iteraciones, en contraposición a desarrollar diferentes partes del núcleo jugable perfectas, tal y como lo hacían anteriormente. De hecho, la agilidad era una de las cosas que ya destacaban en el post-mortem del Resistance:Fall of Men que apareció en la Game Developer Magazine de Febrero 2007.

Automatizando el proceso de build de tu proyecto (1/n)

2008-12-21T13:00:00.001+01:00

Al fin he terminado un pequeño proyecto personal que he estado realizando en mis ratos libres, que es la definición de un estándar personal para la organización y generación de mis proyectos en .NET. Suena muy rimbombante, pero no significa otra cosa que definir una estructura de directorios para organizar los diferentes ficheros que componen un proyecto (resources, ficheros de código), así como automatizar el proceso de build de un proyecto y los resultados generados (compilar, ejecutar tests y generar informes sobre el estado de la generación, etc).

Herramientas para automatización del proceso de build

En mi caso, el proceso de build de un proyecto incluye:

Compilar todos los módulos que componen el proyecto a partir de la última versión del código fuente(obteniendo dicho código del servidor de control de código)
Ejecutar los test-unitarios
Generar informes, en mi caso sólo del resultado de la ejecución previa de los test unitarios
Generar la documentación
Preparar y empaquetar todo lo generado para distribuir la última versión de la build

Al ser un proceso altamente repetitivo -y por tanto propenso a errores- es un gran candidato a una automatización. Para ello existen varias herramientas, siendo las más conocidas en el caso de .NET:

MSBuild propiedad de y utilizado por Microsoft (de hecho los ficheros *.*proj de Visual Studio son ficheros de definición de MSBuild).
NAnt, un port de la herramienta Ant que se creo para projectos Java.

He decidido implementar la automatización utilizando NAnt, simplemente por la posibilidad de aprovechar el conocimiento de cara a necesitar hacer algo con Ant para móviles, y porque me parecía subjetivamente más maduro: Microsoft lanzó MSBuild al público de forma gratuita e indepente de Visual Studio hace relativamente poco, y NAnt comenzó su andadura allá por el 2001. Además éste último es open source.

Ambas herramientas se basan en conceptos similares:

targets: Representa un resultado que queremos obtener en el proyecto. Típicos ejemplos de targets pueden ser 'clean', que elimina los ficheros binarios y temporales para dejar el código fuente preparado para compilar de nuevo, un target 'compile' para compilar el código y regenerar todo el proyecto, etc.
tasks: Las tareas son la base con las que realizamos las operaciones para llegar a un target. Están predefinidas, aunque podemos agregar tareas externas (NantContribes un proyecto para agregar tareas útiles no incluidas en el proyecto NAnt), así como crear tareas personalizadas. Típicas tareas pueden ser operaciones sobre los ficheros (mover, copiar, borrar o generar nuevos ficheros o directorios), llamar al compilador con una lista de ficheros para que genere un ejecutable o una librería, etc.
properties: Las propiedades nos permiten definir pares clave-valor dentro de la configuración. Se puede pensar en ellas como variables. Por ejemplo la propiedad project.sourcedirectory, podría representar el path al directorio donde se encuentran los ficheros de código del proyecto

Los ficheros de configuración de estas herramientas se construyen como ficheros XML con extensión .build, donde definimos los targets del proyecto y las tareas que lo componen, definimos las propiedades, etc.

ejemplo de fichero básico de build para NAnt

<project name="example nant-build">
	<property name="mySolutionPath" value="C:\dev\testproject\solution.sln" />
	<property name="myReferencesDir" value="C:\dev\testproject\references" />

	<target name="compile">
		<solution 
			configuration="Release"
			solutionfile="${mySolutionPath}">
    			<projects>
        			<include name="${mySolutionPath}\other.csproj" />
	    		</projects>
    			<excludeprojects>
				<include name="${mySolutionPath}\toexclude.csproj" />
    			</excludeprojects>
    			<referenceprojects>
        			<include name="${myReferencesDir}\*.dll" />
	    		</referenceprojects>

			<echo message="Solution generated sucessfully!" />
		</solution>
	</target>
</project>

El anterior fichero de configuración define dos propiedades: 'mySolutionPath y myReferencesDir', el valor de las cuales es el path al fichero de solución Visual Studio del proyecto, y el path a un directorio de referencias necesarias para el proyecto respectivamente. Estas propiedades se encuentran bajo la etiqueta 'proyect' así que son visibles para todo target definido dentro de este proyecto. Las propiedades se referenciarán más tarde en el fichero de configuración encerrándolas entre ${ <nombre_propiedad> }

A continuación se define un target llamado 'compile', el cual consta de una sóla tarea: 'solution'. Esta tarea simplemente compilará el proyecto usando un fichero de solución (.sln) de visual studio especificado, por lo que equivale a ejecutar el comando Build (Generar) en dicho IDE. Por supuesto podemos tener tanto control como queramos a la hora de compilar el código, y podemos si así fuera necesario llamar directamente al compilador de C# con los argumentos apropiados y una lista de ficheros concretos, lo que puede ser muy útil en algunos casos (ahora mismo me viene a la cabeza que sería muy útil para generar http://en.wikipedia.org/wiki/.NET_assembly#Satellite_assemblies :))

La tarea 'solution' a su vez contiene varios parámetros definidos tanto por medio de atributos XML como de etiquetas hijo:

Atributos XML:
- configuration: especifica la configuración a aplicar a la hora de generar el código (Release, Debug), de la misma manera que podemos hacer en Visual Studio
- solutionfile: indica la ruta donde se encuentra el fichero de solución de Visual Studio. No es necesario que sea un path absoluto, puede ser relativo a la ruta donde se encuentra ubicado el fichero .build
etiquetas hijo:
- projects: define una lista de ficheros de proyecto a generar. Por defecto la tarea 'solution' genera todos los proyectos definidos en el fichero de solucion, aunque podría ser necesario especificar que sólo genera un subconjunto de ellos.
- excludeprojects: define una lista de ficheros de proyecto a excluir de la generación
- referenceprojects: define una lista de ficheros que son necesarios referenciar para la generación de la solución
- echo: muestra el texto especificado con el atributo 'message' en la consola

Una vez terminado, sólo tendremos que ejecutar nant desde la línea de comandos especificando el target (si sólo hay un fichero de build en el directorio, nant lo usa automáticamente):

nant compile

Y automágicamente el proyecto se generará ;)

Como veis esta "simple" tarea reemplaza al comando build de visual studio. Puede parecer una tontería teniendo ya disponible el comando en el editor, pero la idea es que podamos generar el proyecto entero sin necesitar que Visual Studio esté ejecutándose (aunque NAnt requiere que el SDK de .NET, MSBuild u otras herramientas estén instaladas en el sistema para ser capaz de ejecutar según qué tareas )

La idea es construir un fichero de build para NAnt que realice las tareas necesarias para nuestro proyecto. Por ejemplo, esto es lo que se muestra cuando ejecutamos el target tarea "Help" (que es la tarea por defecto) sobre mi fichero de configuración:

Buildfile: file:////ProjectGenerator/buildfile.build
Target framework: Microsoft .NET Framework 3.5
Target(s) specified: Help 

   [tstamp] lunes, 15 de diciembre de 2008 23:28:49.
   [tstamp] build-process.date = 15-12-2008 23h 28m 49s.
     [echo] [INFO] Including external files:
     [echo]  -> development-tree.definition.buildinclude
     [echo]  -> external-tool.paths.buildinclude
     [echo]  -> project.properties.buildinclude
     [echo] 
     [echo] [INFO] Performing checks... 
     [echo]  --> Checking development tree properties
     [echo]  --> Checking project properties...
     [echo] [OK] All checks passed
     [echo] 
     [echo] [INFO] Using default solution file:
     [echo]  -> AutomatedProjectGenerator.sln
     [echo] 
     [echo] [INFO] Using default versioning file:
     [echo]  -> version.number
     [echo] 
     [echo] [INFO] Using default guid file:
     [echo]  -> guid.number
     [echo] 
     [echo] [INFO] Using default assemblyl file:
     [echo]  -> CommonProjectAssembly.cs
     [echo] 
     [echo] [INFO] Using tests reports file:
     [echo]  -> UnitTestsReports
     [echo] 

Help:

     [echo] -----------------------------------------------------
     [echo]  'AutomatedProjectGenerator' build file Targets   
     [echo] -----------------------------------------------------
     [echo] 
     [exec] 
     [exec] Skeleton file for the build process
     [exec] 
     [exec] Default Target: 
     [exec] 
     [exec] Help                - Lists the available targets in the build file
     [exec] 
     [exec] Main Targets: 
     [exec] 
     [exec] build               - Builds project and runs unit tests, placing the results in the publish directory
     [exec] build-debug         - Like the build target, but using the debug configuration when building
     [exec] clean               - Cleans up the build environment
     [exec] CodeAnalisys        - Analyses the generated assemblies using FXCop
     [exec] Compile             - Compiles the project
     [exec] GenerateDoc         - Generate documentation files
     [exec] GenerateGUID        - Generates a new GUID for the project
     [exec] GenerateReports     - Generate unit tests and coverage reports
     [exec] Get                 - Grabs the code from the repository
     [exec] Help                - Lists the available targets in the build file
     [exec] IncreaseBuildNumber - Updates project's version build number
     [exec] IncreaseMajorNumber - Increases project's version major number
     [exec] IncreaseMinorNumber - Increases project's version minor number
     [exec] MoveToLastBuild     - Moves last generated build files to the publish directory
     [exec] publish		- Zips all assets generated in the publish directory, getting it ready to be deployed
     [exec] RepositoryCleanup   - Issues a 'cleanup' command to the repository
     [exec] RunTests            - Run unit tests
     [exec] UpdateDataAssembly  - Updates data assembly file and commits it to the repository
     [exec] UpdateVersionFile   - Updates the versioning file and commits it to the repository
     [exec] 
     [exec] Sub Targets: 
     [exec] 
     [exec] CloseLogs           
     [exec] CommitDir           
     [exec] ComputeIncludeList  
     [exec] Failure             
     [exec] StartLogs           
     [exec] Success             
     [exec] 
     [exec] 
     [echo] [INFO] Subtargets should not be called by the user

CloseLogs:


Success:

     [echo] [OK] BUILD SUCCEDED See build.lastbuild.log for details

BUILD SUCCEEDED

Total time: 1.1 seconds.

En posteriores entradas describiré un poco cómo he organizado la estructura de directorios para un proyecto y colgaré instrucciones y todo lo necesario para utilizar la configuración de nant que he creado, en caso de que a alguien le interese.

IronPython & IronPython Studio

2008-12-14T13:40:00.001+01:00

El pasado 10 de diciembre se lanzó la versión 2.0 de IronPython, la implementación del conocido lenguaje dinámico Python que corre bajo .NET. Esto permite, por ejemplo, que podamos acceder a todas las librerías que ofrece el framework.NET utilizando python, lo que unido a sus capacidades como lenguaje de script, puede ser una herramienta muy interesante de cara a desarrollar prototipos o aplicaciones simples. También para todo tipo de aplicaciones supongo, pero en mi caso no domino muy bien el lenguaje como para eso :)

Una de las novedades destacadas es que ahora utiliza el Dynamic Language Runtime lo que le da, por ejemplo, ventajas de cara a la interoperabilidad, algo ya comentado cuando hablé de las mejoras que se esperan para c# 4.0, así como importantes mejoras de rendimiento. También como novedad, el código está disponible como código abierto bajo la Microsoft Public License.

La versión 2.0 de IronPython es compatible con CPython 2.5, que no es la última versión existente del lenguaje, ya que hace escasamente 10 días que salió la versión 3.0 de éste último. Sin embargo la versión 3.0 de Python no es compatible con las anteriores al incluir nueva funcionalidad y además reorganizar las librerías estándar del lenguaje, así que a día de hoy la versión 2.5 es la que más base de código tiene.

Relacionado con este proyecto tenemos IronPython Studio, que utiliza Visual Studio 2008 para propocionar un IDE para IronPython, incluyendo plantillas de proyecto iniciales, resaltado de sintaxis y autocompletado de código. Para la instalación podemos elegir entre integrarlo con una instalación ya existente de Visual Studio, o bien instalarlo como un componente independiente.

El único problemilla que tiene actualmente es que sigue basado en IronPython 1.0, así que habrá que esperar a que se actualice a la nueva versión.

Links de la sem... de cuando buenamente pueda

2008-12-08T22:13:00.001+01:00

Bueno, pues más que links de la semana mejor lo empezaré a denominar F.A.I.L (Fun, Aperiodic and Interesting Links)

Lo primero un interesante artículo de introducción sobre la codificación de caracteres por parte de Joel Spolsky: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Artículo sobre cómo funcionan los locks de acceso concurrente en .NET. Empieza a alto nivel y baja hasta la implementación en ensamblador. Blog muy recomendable el de Jeff Moser, que pasa a engrosar mi lista de blogs de desarrollo :)
Relacionado con el tema anterior (de hecho lo he descubierto por un link en el blog anterior, cómo implementar de un Reader-Writer lock, es decir, un lock que permite el acceso de múltiples hilos para lectura pero sólo uno para escritura.
Intesante página sobre desarrollo en Mac, con una sección de screencasts.

No hay muchos links porque me he dado cuenta que la lista de libros que estoy leyendo no ha variado un ápice desde que abrí el blog, así que en vez de mover la rueda del ratón para hacer scroll, me he puesto a pasar páginas

PDC 2008: The Future of C# 4.0 (3/3)

2008-12-01T00:04:00.001+01:00

Y llegamos a la tercera y última entrada de esta mini-serie, donde hablaremos de otra de las características presentadas para C# 4.0: covarianza y contravarianza en tipos genéricos.

Primero explicaremos brevemente lo que es la covarianza y la contravarianza, o al menos simplificar un poco la reseña en la wikipedia ;)

En POO, una jerarquía de herencia puede verse como una relación de órden. Si tenemos por ejemplo esta relación de clases:

y si definimos la relación A ≤ B significando "B es un A" o que "B es más especializado que A", vemos que cumple una relación matemática de orden parcial (cumple las propiedades reflexiva, antisimétrica y transitiva).

Una vez dicho esto, los términos covarianza y contravarianza, se refieren al tipo de sustitución que podemos hacer, siendo B subtipo de A, y podemos entenderla así:

Covarianza	A ≤ B	Podemos sustituir un tipo A por otro más especializado B
Contravarianza	A ≥ B	Podemos sustituir un tipo A por otro más genérico B

Esto lo veremos mejor con ejemplos: considerando la jerarquía anterior, sea un método definido:

B MyMethod(B parameter);

Las llamadas a métodos son covariantes tanto en sus valores de retorno como en el paso de parámetros; es decir podemos retornar un tipo B, o cualquier subtipo suyo, y podemos pasar como parámetro un tipo B, o cualquier subtipo:

void MyMethod(B parameter) { return new D(); }
...
MyMethod( new D() );

Sin embargo en los delegados tenemos contravarianza en el paso de parámetro, es decir dado este delegado la asignación es legal

delegate void MyDelegate(D parameter);
MyDelegate myDelegate; //delegate instance
myDelegate += MyMethod;

La segunda asignación es válida porque en realidad el delegado está especificando que acepta uno de los (potencialmente muchos) subtipos que acepta el método, con lo que estamos aplicando una restricción mas fuerte. Por tanto estamos asignando MyMethod, que recibe un parámetro de tipo B, a un delegado que espera un tipo D, es decir, sustituimos un tipo concreto por otro más genérico.

El problema es que todo esto no se aplicaba con herencia cuando usamos tipos genéricos, es decir estos eran invariantes. No podíamos hacer esto:

public interface IMyInterface<TYPE> { ... }

public static class Tmp
{
	public static IMyInterface<B> GetData() 
	{ 
		return new B[] {new B(), new B()}; 
	}
}

IMyInterface<B> e1 = Tmp.GetData();
IMyInterface<A> e2 = e1; // ERROR

Esto es a priori perfectamente válido, ya que A es más genérico que B, sin embargo no es una asignación válida en C# al carecer de covarianza en valores de retorno para tipos genéricos. Cuando tengamos disponible C# 4.0, podremos indicar que un tipo genérico concreto admitirá covarianza en valores de retorno por medio de la palabra clave out y declarando el tipo genérico :

public interface IMyInterface<out TYPE> { ... }

Para utilizar contravarianza con genéricos usaremos la palabra clave in. Nueva fusilada de la presentación:

public interface IComparer>in T<
{
   int Compare(T x, T y);
}

IComparerobjComp = GetComparer(); //Returns an IComparer 
IComparer strComp = objComp; //Ilegal before 4.0

Queda un punto muy interesante por tratar de la presentación, la novedad de presentar el compilador de C# como un servicio, es decir, podremos llamar al compilador de C# en tiempo de ejecución para compilar el código que queramos y que esté accesible en ese momento. Sin embargo esta característica es similar a una presentada en Mono, y la trataré en una entrada posterior :)

PDC 2008: The Future of C# 4.0 (2/3)

2008-11-25T20:54:00.001+01:00

Seguimos comentando la presentación de Anders Hejlsberg sobre el futuro de C# y las novedades que nos aguardan para la próxima versión.

Ahora le toca el turno a una característica que los usuarios de VB.NET disfrutan también desde siempre y que personalmente no entiendo cómo ha tardado tanto en aparecer en C#: Llamadas a métodos con valores por defecto para los parámetros.

Si has tocado C++ seguramente has echado de menos escribir algo como:

void SomeMethod(string connectionString, int timeout = 1000) {...};
...
SomeMethod("myConnectionString"); //1000ms timeout
SomeMethod("otherConnectionString", 3000);

Esta limitación se puede solventar fácilmente, simplemente escribiendo varias sobrecargas para el método:

void SomeMethod(string connectionString , int timeout = 1000) {...};
void SomeMethod(string connectionString):this (connectionString, 1000) {...}

SomeMethod("myConnectionString"); //1000ms timeout
SomeMethod("otherConnectionString", 3000);

Pero escribir más sobrecargas implica... escribir más código. Eso es algo que el propio compilador podría hacer y que de hecho ya hacía en otros lenguajes, por lo que realmente era una carencia ... curiosa.

Quizá para implorar el perdón de las hordas, además de prometer que a partir de ahora se intentaría que ambos lenguajes (VB.NET y C#) evolucionen de forma paralela para mantener en ambos funcionalidad similar, se añadirá la posibilidad de utilizar parámetros con nombre dentro de métodos con parámetros por defecto. Eso implica que ahora podremos elegir qué parametros por defecto utilizar, y no estaremos limitados a utilizarlos en el orden declarado. ~~Por ejemplo~~Fusilando de nuevo, si tenemos

public StreamReader OpenTextFile(
    string path,
    Encoding encoding = null,
    bool detectEncoding = true,
    int bufferSize = 1024);

Podríamos llamarlo así:

OpenTextFile("C:\mypath");
OpenTextFile("C:\mypath",Encoding.ASCII);
OpenTextFile("C:\mypath",Encoding.ASCII, false);
OpenTextFile("C:\mypath",Encoding.ASCII, false, 2048);

Pero no podríamos llamar a dicho método así:

OpenTextFile(2048);

Es decir, el orden de uso de los parámetros depende de su declaración. De hecho todos los parámetros por defecto deben ser los últimos que se declaren (los que estén "más a la derecha" en la firma del método)

Sin embargo con parámetros por nombre podremos definir el nombre del parámetro que queremos establecer y el compilador utilizará los valores por defecto para el resto si procede. Así, ahora podríamos hacer:

OpenTextFile(bufferSize : 2048, path :"C:\MyPath");

Siendo esta llamada equivalente a

OpenTextFile("C:\MyPath", null, true, 2048);

Por supuesto los parámetros que no tienen un valor por defecto DEBEN aparecer en la llamada. Además los parámetros con nombre se evaluarán en el orden en que aparezcan en la llamada, y no en el orden en el que estén definidos.

Para la próxima entrada comentaremos la última novedad, algo por lo que también hubiera ~~matado~~ pagado: covarianza y contra-varianza con generics.

PDC 2008: The Future of C#4.0 (1/3)

2008-11-23T19:55:00.007+01:00

Hace aproximadamente un mes se celebró la Professional Developers Conference 2008, conferencias dedicadas principalmente a desarrolladores Windows. En esta edición se han presentado múltiples novedades, como el SDK de Microsoft Surface (la pena es que me parece que para conseguirlo hay que comprarse también el aparatito, que no es precisamente barato), han presentado novedades sobre Windows 7, y muchas otra cosas más. Podéis hacer una búsqueda para intentar encontrar una conferencia que contenga un tema que os interese. Las vídeos de las conferencias pueden verse por streaming -siempre que tengas instalado Silverlight- pero también están disponibles para descarga en múltiples formatos; y lo mismo se aplica a las presentaciones utilizadas.

Después del párrafo patrocinado por Microsoft :) vamos a realizar una pequeña serie de posts comentando la presentación que da título a esta entrada y que hasta hoy mismo no he podido mirar: The future of C#, presentada por Anders Hejlsberg, arquitecto jefe del desarrollo del lenguaje C#.

Anders comienza reseñando que las nuevas "tendencias" en programación apuntan a lenguajes de programación declarativos, dinámicos y con soporte para concurrencia, indicando que C# se mueve hacia dichas tendencias:

Programación declarativa: LINQ nos permite especificar los datos que queremos y cómo los queremos, pero la forma última de acceder a ellos y tratarlos no es de nuestra competencia. La ventaja que esto puede tener es que el compilador JIT podría realizar optimizaciones según el tipo de dato al que accedemos.
Lenguajes dinámicos: aunque defensor de los lenguajes y del tipado estático, reconoce muchas virtudes de utilizar un lenguaje dinámico en muchas situaciones. Además, una de las ventajas que tienen los lenguajes dinámicos es la capacidad de metaprogramación. Estos dos aspectos se intentarán mejorar en el lenguaje mediante la palabra clave dynamic y la presentación del compilador de C# como servicio (en próximas entradas :) .
Concurrencia: Aquí ya no hay otro truco que el diseñar la aplicación como un grupo de trabajos independientes y paralelizables. Sin embargo hay ya una extensión al lenguaje llamada .NET Parallel Extensions de la que ya hay disponible una CPT para su descarga.

Pasemos entonces a comentar el primero los añadidos más interesantes de C# presentados:

Programación dinámica: palabra clave dynamic

La ejecución de código dinámico no es algo nuevo en .NET, ya hay un esfuerzo para definir un entorno de ejecución dinámico común en todo .NET: el DLR, que estandariza el sistema de tipos, de enlace dinámico y de generación dinámica de código, de forma que sea accesible para cualquier lenguaje y además permita que las diferentes implementaciones interactúen entre sí de forma más cómoda. Por ejemplo, tanto IronRuby como IronPython, utilizan el DLR. Vamos, que es algo así como el CLR pero en dinámico.

El propósito de la palabra clave dynamic es "comunicarse con cosas que no son una clase .net con tipado estático". Esto se realiza por medio de binders a dichos lenguajes, y como se ve en la figura, entre esas cosas se incluyen propio código .NET enlazado dinámicamente, java script, Python, Ruby, o bien objetos COM. De hecho esta palabra clave está llamada a dejar obsoleta mi librería LateBindingHelper. ~~Por ejemplo~~ Fusilando este código de la presentación, supongamos un objeto Calculator que permite realizar operaciones aritméticas:

Calculator calc = GetCalculator();
int sum = calc.Add(10, 20);

Si queremos utilizarlo usando LateBinding:

object calc = GetCalculator();
Type calcType = calc.GetType();
object res = calcType.InvokeMember("Add",BindingFlags.InvokeMethod, null,new object[] { 10, 20 });
int sum = Convert.ToInt32(res);

Aprovechando para hacer publicidad ^_^ con librería LateBindingHelper se simplificaría a

IOperationInvoker calc = BindingFactory.CreateObjectBinding(GetCalculator());
int sum = calc.Method("Add").AddParameter(10).AddParameter(20).Invoke<int>();

Sin embargo utilizando la palabra clave dynamic, todo quedaría:

dynamic calc = GetCalculator();
int sum = calc.Add(10, 20);

Sin embargo, si cogemos este pequeño código vemos que se están realizando muchas cosas. En la primera línea, la palabra dynamic define una variable con un tipado fuerte. Es decir, una variable declarada con dinamic es de tipo dinámico, que viene a ser una especie de object al poder asignarle cualquier valor. Sin embargo no podemos hacer castings implícitos:

dynamic x = 1;
int i = x; //NO!

En la segunda estamos invocando el método Add de forma dinámica, esto es: el enlace al método se realiza en tiempo de ejecución, y esto ocurre para cualquier operación en la que esté involucrada una variable dynamic. Además, el resultado de la operación se convierte también de forma dinámica al tipo que asignamos, int en este caso.

Es indudable que la nueva keyword dynamic muy útil en muchos casos. Aunque en algunos sitios ya ponen el grito en el cielo diciendo que podría sobreutilizarse y derivar en diseños pobres. Yo digo que 'como todo'. Prácticamente cualquier cosa de un lenguaje la puedes utilizar de una manera incorrecta manera y acabar creando un diseño pobre.

Fluent Interfaces

2008-11-16T17:36:00.001+01:00

Navegando un poco e investigando sobre ideas y tecnología a usar en mi PFC llegué a uno de los muchos artículos de Martin Fowler donde se discute una forma de generar una API, que aunque ya conocía en esencia, no sabía que tenía un nombre: Fluent Interfaces

Básicamente cuando se crea un "interface fluido" se pretende que las operaciones que puedes realizar en un objeto dependan del contexto generado por la operación previa. Con un ejemplo es mucho más sencillo, y corto y pego el que aparece en la wikipedia:

GlutApp app(argc, argv);
app.setDisplayMode(GLUT_DOUBLE|GLUT_RGBA|GLUT_ALPHA|GLUT_DEPTH); // Set framebuffer params
app.setWindowSize(500, 500); // Set window params
app.setWindowPosition(200, 200);
app.setTitle("My OpenGL/GLUT App");
app.create();

El código de arriba crea una ventana de visualización OpenGL usando GLUT. Bien, pues el mismo código utilizando el tipo de interface que discutimos sería:

FluentGlutApp app(argc, argv)
     .withDouble().withRGBA().withAlpha().withDepth()
     .at(200, 200).across(500, 500)
     .named("My OpenGL/GLUT App");
app.create();

Personalmente creo que el último ejemplo expresa de forma más clara las operaciones a realizar (inicialización), y sobre todo a qué objeto están dirigidas. Al respecto, y como curiosidad, si habéis utilizado Rhino Mocks como librería de Mocks para vuestros casos de prueba, comprobaréis que a partir de la versión 3.2 añade una sintaxis fluida

Dándole vueltas al asunto, me di cuenta que tenía un proyecto previo que podría beneficiarse -y mucho- de este tipo de interfaces: mi librería para simplificar llamadas utilizando Late Binding en C#, de la que hablé en una entrada anterior. Así que dejando aparcado el PFC un tiempo y dedicándole un par de días, he creado la versión ~~2.0~~ 2.1 de la librería, cuyo código está subido ya al repositorio.

Una de las mejoras que provoca el nuevo interface es la llamada de métodos con múltiples parámetros. Por ejemplo, supongamos una operación que recibe 2 parámetros, uno de ellos por referencia:

void MyClass.MyOperation(string command, ref int result);

Con la versión 1.* tendríamos que hacer :

ILateBindingFacade lb = LateBindingFactory.CreateObject(typeof(MyClass) );
string cmd = "myCommand";
int result;
object[] args = Args.Build(cmd, result);
lb.Call("MyOperation", Args.ByRefIndexs(1), args);
result = args[1];

Con la nueva versión sin embargo el código queda así:

IInvoker invoker = LateBindingFactory.CreateObject(typeof(MyClass) );
object result;
invoker.Method("MyOperation")
	.AddArgument("myCommand")
	.AddRefArgument(result)
	.Invoke();

result = invoker.LastCallArguments[1];

Vale que es "mi" librería y que los niños de uno nunca son feos, pero a mi me parece muchísimo más elegante y simple que la primera versión, y no sólo se queda en elegancia, sino que las operaciones permitidas dependen del contexto como había hablado anteriormente. Por ejemplo, si en un objeto IInvoker llamamos a la operación Method para especificar el nombre de la operación a invocar sobre él, los únicas operaciones que pueden ejecutarse son AddParameter, AddRefParameter e Invoke, que son las únicas que tienen sentido.

La legibilidad aumenta según más complejo es el uso. Esto se puede ver si retomamos el código para controlar Microsoft Word que tenía en la versión 1.3 de la librería, y lo comparamos con la nueva versión:

ILateBindingFacade word = LateBindingFactory.CrateAutomationBinding("Word.Application");
            
//Get Word object 
ILateBindingFacade wordDoc = word.Get<ILateBindingFacade>("Documents").Call<ILateBindingFacade>("Add");
ILateBindingFacade selection = word.Get<ILateBindingFacade>("Selection");

string str = "Hello World!";

word.Set("Visible", true);

selection.Call("BoldRun");

foreach (char c in str)
{
	selection.Call("TypeText", Args.Build(c.ToString()));
        System.Threading.Thread.Sleep(200);
}

word.Call("Quit", Args.Build(0) );

Y la nueva versión 2.1 que lava más blanco:

IInvoker wordApp = BindingFactory.CreateAutomationBinding("Word.Application");
//Get Word object 
IInvoker document = wordApp.Property("Documents").Get<IIinvoker>();
            
document
    .Method("Add")
    .Invoke();

IInvoker selection = wordApp
			.Property("Selection")
			.Get<IInvoker>();

string str = "Hello World!";

//Make workd visible
wordApp
    .Property("Visible")
    .Set(true);

//Activate bold
selection
    .Method("BoldRun")
    .Invoke();


foreach (char c in str)
{
	selection
		.Method("TypeText")
		.AddParameter(c.ToString())
		.Invoke();

        System.Threading.Thread.Sleep(200);
}

//Quit
wordApp
    .Method("Quit")
    .AddParameter(0)
    .Invoke();

Sólo queda hacer la pregunta de rigor, ¿qué interface creeis que sería más cómodo de utilizar?

[CSharp]Fun with Windows Handlers (3/3)

2008-10-25T16:29:00.004+02:00

Y por fin la tercera y última entrada, donde -por fin- utilizaremos todo lo que hemos aprendido anteriormente para realmente hacer algo útil :)

Ya vimos anteriormente los conceptos de parent y owner de un control, ahora vamos a ver cómo podemos forzar esos comportamientos en una aplicación por medio de los Handlers de la ventana y de llamadas a la API Win32.

Al final de la entrada se puede descargar el proyecto de visual studio 2005 utilizado para las capturas de pantalla de este post. La aplicación crea tres formularios simples: un reloj con un par de botones que simplemente muestran un aviso al ser pulsados, un formulario para guardar una imagen, y un formulario con diferentes botones de control para activar y desactivar las operaciones entre los anteriores formularios.

Botón 'Make Owner'

Al pulsar este botón provocará que el formulario 'ClockWindow' se convierta en el Owner del formulario 'PictureBox'. Por tanto éste último siempre será dibujado por encima del primero:

Para conseguir este efecto, usaremos la función SetWindowLongPtr(), que sirve para cambiar los atributos de una ventana. Si firma en P/Invoke es:

public static IntPtr SetWindowLongPtr(IntPtr hWnd, int nIndex, IntPtr dwNewLong)

Donde hWnd es el handle de la ventana a la que queremos cambiar un atributo, nIndex es una constante que define el atributo a cambiar, y dwNewLong sirve para establecer el nuevo valor.

En este caso para cambiar el owner de la ventana, tenemos que usar una constante con un desafortunado nombre: GWL_HWNDPARENT. Ésta constante está definida en winapi.h, y tiene el valor -8. Su nombre es desafortunado porque realmente no tiene nada que ver con establecer la clase padre (parent) y puede llevar a equívocos.

Para establecer, por ejemplo, que el formulario 'ClockWindow' sea el propietario de 'PictureBox' llamaremos a la función de la siguiente manera:

WinAPIDeclarations.SetWindowLongPtr(
pictureWindowForm.Handle,
-8,
clockWindowForm.Handle);

Y para volver a dejar todo como estaba, lo que haremos será establecer el Handler del owner de 'PictureBox' como IntPtr.Zero, lo que equivale a establecer el escritorio como propietario:

WinAPIDeclarations.SetWindowLongPtr(
pictureWindowForm.Handle,
-8,
IntPtr.Zero);

Botón 'Make Parent' y 'Make Parent to Button'

Seguimos con la función SetParent(), cuya firma para P/Invoke se define:

[DllImport("user32.dll")]
public static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);

Con esta función podemos forzar que un control cualquiera se convierta en el padre del otro, y por tanto provocará que el hijo se dibuje dentro del rectángulo de cliente del control padre, ya sea un formulario u otro control:

Hay que destacar que tanto esta operación como la anterior funcionan para cualquier ventana de la que podamos obtener el handle. Por tanto podemos conseguir cosas como esta:

Botón 'Disable refresh'

Esta operación permite activar o desactivar el repintado de una ventana. Utilizaremos la función SendMessage() para ello y el mensaje WM_SETREDRAW. La firma P/Invoke de la función y el valor del mensaje es:

[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)]
public static extern IntPtr SendMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);

public static readonly uint WM_SETREDRAW = 0x000B;

Para desactivar el repintado de una ventana haremos:

IntPtr result = WinAPIDeclarations.SendMessage(
clockWindowForm.Handle,
WinAPIDeclarations.WM_SETREDRAW,
(IntPtr)0,
IntPtr.Zero);

Y para volver a activarlo:

IntPtr result = WinAPIDeclarations.SendMessage(
clockWindowForm.Handle,
WinAPIDeclarations.WM_SETREDRAW,
(IntPtr)1,
IntPtr.Zero);

Botón 'Disable Input'

Esta operación permite activar o desactivar el procesado de input para una ventana, es decir, podemos hacer que la ventana no responda a ningún tipo de entrada de datos (con ratón o teclado) de forma que en la práctica no se puede interactuar con ella. Para ello disponemos de otra función con un nombre no muy descriptivo: EnableWindow(), que tiene la firma:

[DllImport("user32.dll")]
public static extern bool EnableWindow(IntPtr hWnd, bool bEnable);

Viendo los argumentos es bastante fácil de usar si eres capaz de intuir por el nombre lo que hace; para desactivar la entrada de input haremos:

EnableWindow(clockWindowForm.Handle, false);

y para desactivarla:

EnableWindow(clockWindowForm.Handle, true);

De nuevo, estas dos últimas operaciones pueden aplicarse a cualquier ventana sabiendo su handle, así que podemos desactivar el repintado o la entrada de datos de una ventana externa. Esto puede ser útil en ciertos casos pero hay que tener mucho cuidado: si olvidamos restablecer el estado anterior o nuestra aplicación se cierra inesperadamente podríamos dejar una aplicación externa sin respuesta, por lo que el usuario tendría que matar el proceso y recargarla, potencialmente perdiendo datos. Hay que ser muy cuidadoso al utilizar estas operaciones.

También hay que avisar a posibles usuarios de Mono de que al estar haciendo llamadas específicas a la API de Windows, este código no es portable.

Descargar ejemplo para VisualStudio 2005

[CSharp]Fun with Windows Handlers (2/3)

2008-10-18T20:46:00.008+02:00

Siguiendo con la entrada anterior, veremos ahora una pequeña muestra de alguna cosa divertida conociendo el Handler de una ventana.

Si la ventana pertenece a nuestra aplicación, y sólo en ese caso, podemos obtener a partir del handle, la instancia de la clase Form al que está asociado:

Form formApp = (Form)Form.FromHandle( myAppWindowHandle );

Si el handle no pertenece a una ventana creada dentro de nuestra propia aplicación, Form.FromHandle retorna null, imagino que será por cuestiones de seguridad. El caso es que usando funciones de Win32 API por medio de P/Invoke podemos saltarnos en algunos casos esta seguridad.

Antes de mostrar lo que podemos hacer, tendremos que presentar dos conceptos que se aplican en las ventanas de Windows. Si, es un momento teórico, pero necesario.

Parent Window

En Windows, todo elemento visual (widgets), desde el formulario principal a los botones se consideran... windows (buen nombre para no confundir a la gente ¿eh? ) Una mejor manera de denominar a los widgets es usar la nomenclatura usada en .NET: Todo es un Control.

Una aplicación de Windows consiste en una jerarquía de controles: cada control puede a su vez ~~contener a otros~~, ser padre de otros, creando una jerarquía en forma árbol. En Visual Studio podemos ver esa jerarquía por medio del menú View/Other Windows/Outline Document.

Por ejemplo, si tuviéramos el siguiente formulario la jerarquía sería la mostrada por la imagen a su derecha:

Sin embargo si ahora añadimos un GroupBox e introducimos el botón en él, tendríamos la siguiente ventana y jerarquía:

Una vez dicho esto, creo que queda claro de forma intuitiva lo que es una ventana padre o una ventana hija dentro de la jerarquía. Lo que tenemos que tener en cuenta que una ventana hija se posiciona en coordenadas relativas a la ventana padre, y que siempre se mantiene dentro de los límites del área de cliente de una ventana.

Owner Window

Esta es más sencilla: una ventana se considera propietaria de otra cuando se considera parte fundamental de la ventana propietaria. Pro ejemplo, si desde nuestra aplicación creamos un MessageBox, o mostramos un diálogo de selección de fichero, nuestra aplicación es la propietaria de éstas ventanas: nuestra aplicación las crea y las gestiona, pero no dependen de una jerarquía de controles dentro de la ventana principal. Esas ventanas no tienen por qué se modales, por ejemplo, las típicas ventanas flotantes de una aplicación de retoque fotográfico tienen como propietaria a la ventana de la aplicación principal:

Las ventanas que son propiedad de otra tienen la particularidad de que se pueden dibujar en cualquier parte del escritorio, pero siempre se muestran por encima de la ventana propietaria.

UPDATE: Otro comportamiento muy importante de una ventana que tiene como propietaria a otra es que si cerramos la ventana principal, todas las ventanas de las que la ventana principal sea propietaria también se ocultarán.

Y por fin, veremos cómo hacer alguna cosa interesante con un handler en la tercera y última entrada de esta mini-serie.

[CSharp]Fun with Windows Handlers (1/3)

2008-10-17T01:39:00.012+02:00

Hay una cosa segura: .Net tiene sus limitaciones. Al menos, si lo comparamos con las operaciones que teníamos disponibles con la API Win32, veremos que no podemos hacer absolutamente todo lo que hacíamos con ésta última. Para solucionar este eventual problema tenemos Platform Invocation Services, más conocido como PInvoke (o P/Invoke), que nos permite hacer llamadas a código nativo implementadas en una DLL desde código administrado.

Debido a que las estructuras de datos utilizadas en código nativo son distintas a las de código administrado, debemos realizar un proceso conocido como Marshaling, que grosso modo viene a significar transportar datos entre diferentes contextos. Muy genérico ¿verdad?.

Este proceso de adecuación de los datos es prácticamente automático. Lo único que tenemos que hacer es indicarle al framework .net la función de la Dll que queremos utilizar, y decirle cómo debe traducir las estructuras de datos. Y ni siquiera tenemos que perder el tiempo en ello, ya que gracias ~~a la página~~ al wiki PInvoke.net, tenemos acceso a un motor de búsqueda donde sólo debemos introducir el nombre de la función que buscamos y obtendremos el código necesario para usarla, listo para cortar y pegar. Aún así daremos una pequeña explicación:

Para usar una función que exporta una Dll tenemos que seguir los siguientes pasos:

Crear una función estática y con el keyword extern.

Marcamos la función con el atributo DllImport, al cual pasamos como parámetro el nombre de la Dll que contiene al método.

La función por supuesto debe tener los parámetros adecuados a lo tipos de .NET.

Por ejemplo, la función Win32 API FindWindow tiene esta definición:

HWND FindWindow( LPCTSTR lpClassName, LPCTSTR lpWindowName );

Esta función recibe un puntero a una cadena con la nombre de la clase con la que se registró la ventana (ojo esto no tiene que ver con clases de POO, sino con otro tipo de clase), y otro puntero a una cadena con el nombre de la ventana (lo que sería el título o caption), retornando el HANDLE de la ventana si la encuentra. Bien, esto se traduce en .NET con el siguiente método de clase (en .NET no existen las funciones por separado, todo tiene que ser parte de un objeto)

public static class Win32API{    [DllImport("user32.dll")]public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);}

Vemos que el Handler de la ventana se traduce por una estructura System.IntPtr, y los punteros a cadenas por strings. Ahora podremos llamar a la función, por ejemplo:

IntPtr hwn = FindWindow(null, "título de la ventana");

Y buscaría la ventana con dicho título ignorando su clase de ventana, retornando el handler a la ventana (o IntPtr.Zero si no se encuentra una ventana con ese título)

Teniendo el Handler de una ventana podemos controlar prácticamente todo si sabemos lo que hacemos. Y esta función nos permite buscar y obtener el handler de cualquier ventana. Aunque no sea de nuestra aplicación. Aunque ni siquiera haya sido generada por código .NET...

Veremos algunos conceptos más en la siguiente entrada.

PS: Como nota curiosa, podemos llamar a nuestro método estático como queramos, siempre que en el atributo [DllImport] le indiquemos el nombre real de la función de la Dll que pretendemos importar:


[DllImport("user32.dll", EntryPoint="FindWindow")]
public static extern IntPtr BuscaHandlerDeVentana(string lpClassName, string lpWindowName);

Como vemos si el parámetro EntryPoint no está disponible, se toma como el mismo el nombre del método estático.

PPS: Existen otras maneras de obtener un handle de la ventana. Si tenemos un objeto System.Windows.Forms.Control (lo que incluye un System.Windows.Forms.Form), éste expone la propiedad Handle, que nos devuelve el Handler de la ventana.

Del mismo modo la clase System.Diagnostics.Process, expone el método estático GetProcesses(), que nos devuelve una lista con todos los Procesos en ejecución (podemos buscar por PID, nombre, etc). A su vez una instancia de la clase System.Diagnostics.Process expone el método Handle, con el Handler del proceso (que suele coincidir con el de la ventana principal).

UPDATE: La clase Process expone una propiedad denominada MainWindowHandle, que SI devuelve el handle de la ventana principal del proceso :)

Links de la semana

2008-10-01T18:44:00.005+02:00

Algo retrasados, pero aquí están los links de la "semana"agrupados un poco...

Test Driven Development

Google nos ofrece Moq, una librería de Mocks, simple de utilizar y aprovechando las características del framework .NET 3.5. La verdad es que sin haberla probado pero viendo los pequeños snippets de código de la web tiene una pinta muy interesante. Yo he estado usando Rhino Mocks, y aunque es muy potente, es un lío que te cagas algo compleja al principio.
Y más Mocks, pero esta vez para J2ME. MockME es un mock completo de las librerías que conforman la especificación J2ME. De esta forma podemos escribir casos de prueba para nuestra aplicación J2ME, pero sin necesidad de ejecutarlos en el móvil.

Visual Studio

Snippet Designer te permite crear snippets de código para Visual Studio de forma visual, lo que es más intuitivo y cómodo.

Miscelánea:

Si eres el poseedor de una PlayStation Eye, y además usas Windows, aquí tienes a un campeón que se ha currado un driver para la misma.
Blog oficial de google sobre Mac, con novedades y utilidades centradas en lo relacionado con Apple.
Booklet Creator es una página web a la que le puedes subir cualquier PDF y te lo transforma para que puedas imprimirlo a dos caras como un libro. Muy útil si el driver de tu impresora no te permite hacerlo de serie, o quieres llevar a imprimir el PDF directamente a una copistería.
OpenPandora. Una consola open source, al estilo de la GP2X o su antecesora la GP32, que por fin está a punto de ser lanzada. Destacan sus especificaciones técnicas:

* ARM® Cortex™-A8 600Mhz+ CPU running Linux
* 430-MHz TMS320C64x+™ DSP Core
* PowerVR SGX OpenGL 2.0 ES compliant 3D hardware
* 800x480 4.3" 16.7 million colours touchscreen LCD
* Wifi 802.11b/g, Bluetooth & High Speed USB 2.0 Host
* Dual SDHC card slots & SVideo TV output
* Dual Analogue and Digital gaming controls
* 43 button QWERTY and numeric keypad
* Around 10+ Hours battery life
Vale, lo de la batería no me lo trago hasta que no lo vea, y aunque guapa lo que se dice guapa, la consola no es, tampoco es un adefesio. Pero sus specs son impresionantes, y el hecho de que sea abierta es su principal virtud. Su precio es de 250€, que tal y como está el mercado es bastante competitivo. Eso si, si estás interesado más te vale reservar ya porque sólo van a lanzar 3000 en lo que queda de año.

Y la próxima "semana", más ;)

[C#] Late binding helper library

2008-09-22T23:57:00.006+02:00

Bueno, pues cuelgo un nuevo y sencillo proyectillo de librería para facilitar las llamadas usando Late Binding en C#. La verdad es que es un poco pesado usar Late Binding en C#, y como contraste en VB lo simplifican en mi opinión sobremanera:

Dim lateBindingObject As Object
lateBindingObject = CreateObject("Word.Application")
lateBindingObject.Visible = True
lateBindingObject.Quit(0)

Esto ~~es lo que hay que hacer en C#~~ lo que hace realmente el compilador de Visual Basic sin que te enteres (tx to Reflector):

object lateBindingObject = RuntimeHelpers.GetObjectValue(Interaction.CreateObject("Word.Application", ""));
NewLateBinding.LateSet(lateBindingObject, null, "Visible", new object[] { true }, null, null);
NewLateBinding.LateCall(lateBindingObject, null, "Quit", new object[] { 0 }, null, null, null, true);

Usando mi librería esto se transforma en:

ILateBindingFacade word = LateBindingFactory.CreateAutomationLateBinding("Word.Application");
word.Set("Visible", true);
word.Call("Quit", Args.Build(0));

Que simplifica un poco las cosas, o al menos eso espero. Y aprovechando el tema he escrito un artículo en CodeProject explicando un poco el funcionamiento, aunque eso si en inglés.

Tip visual studio: Watch genérico para la excepción en curso

2008-09-22T17:13:00.000+02:00

Leo en el blog de Sara Ford, en el que cada día se añade un 'tip of the day' sobre visual studio, una forma sencilla de añadir un watch para que muestre la excepción que estamos tratando dentro de un bloque catch.

Basta con añadir $exception:

Comentarios de la semana y estreno

2008-09-20T20:40:00.001+02:00

Bueno, lo primero es lo primero:

CrazyPointer Proudly Presents

The aiCon

Si desde tu iPhone (aifón) o tu iTouch (aipó tach) decides crear un acceso a la pantalla de inicio, este será el icono que te encontrarás. Si ya habías creado el acceso, además de llevarte +20 kudos por tu buen gusto, tendrás que borrarlo y volverlo a crear si quieres ~~disfrutar de esta obra de arte~~ tener un icono más elaborado que el que se crea por defecto.

Y ya de paso para asegurarme de que al menos actualiza esto cada 7 días, pues qué mejor momento que el fin de semana para recopilar un poco todas esas noticias y artículos interesantes que te vas encontrando a lo largo de la semana en el trabajo(*) en casa, o las nuevas aplicaciones o utilidades descubiertas. Así de paso el blog me sirve de sistema de referencia :)

Si, lo se, es una idea tan original que no entiendo cómo se me ha ocurrido a mi solo. Pero bueno, a lo que íbamos:

Enlaces de interés sobre programación

Lista de websites con retos de programación, obtenido de StackOverflow.
Provider de ADO.NET para SQLite, junto con un gestor de SQLite en forma de extensión para firefox.
eBook gratuito sobre Coding Guidelines para .NET

Páginas web:

www.stackoverflow.com Esta ya la describí en una entrada anterior. Nada más que añadir.
www.gamedevkicks.com Pagina web con kicks sobre programación de videojuegos.

Un par de aplicaciones web interesantes:

Evernote.

Sirve para gestionar todo tipo de notas y apuntes, y formar una pequeña base de datos. Las notas se organizan en notebooks, y además permite aplicarle etiquetas a las mismas. Permite también hacer búsquedas en ellas, incluso guardando esas búsquedas como accesos directos. Sin embargo la característica más importante es que en Evernote puedes hacer búsquedas por el contenido de las notas, incluso si estas son imágenes, ya que aplica OCR a la mismas.

También permite enviar directamente notas utilizando una dirección de correo electrónico, o especificar que los notebooks que quieras sean accesibles públicamente via Web

Y por si fuera poco, además tiene disponibles clientes de escritorio para Windows y Mac que se sincronizan con la web para un acceso offline. También tiene un cliente para SmartPhones y para iPhone / iTouch pero al menos en éste último no almacena las notas para su visionado offline, con lo que pierde toda la utilidad a no ser que estés contactado 24/7 con algún plan de datos, o tengas una WiFi cerca.

Puedes añadir notas manualmente ya sean texto o dibujos (el cliente de escritorio permite dibujar las notas) o bien de forma automática realizando capturas de pantalla (totales o parciales). Por último dispone de una extensión de firefox para capturar con un sólo clic la página actual, asignarla a un notebook y aplicarle etiquetas.

Y por último, es gratuito. Tienes un límite de datos de notas que puedes subir al mes, y si necesitas más entonces puedes solicitar una cuenta premium, que cuenta con un límite mucho mayor.

ToodLedo (versión iPhone)

Es un gestor de tareas online. Es gratuito con opciones de pago, pero la versión básica es muy, muy completa. De lo mejor es que permite importar y exportar a prácticamente todo: Outlook, iCal, Google Calendar, Palm OS, ficheros de texto, CSV, XML, y la mejor, añadir tareas enviando un e-mail.

Dispone también de servicios para integrarse con otras páginas web como Netvibes o iGoogle y Google Calendar, añadir un Gadget para MacOS, una extensión para firefox que permite acceder a las listas de tareas como una barra lateral o añadir tareas desde el propio navegador incluso dispone de una guía para utilizar Toodledo para seguir la metodología GTD,.

Una característica curiosa es el booklet, que no es más que la posibilidad de exportar los datos a un PDF que puedes imprimir y recortar para que te quede accesible en papel:

El único problema que se le puede achacar es que no dispone de clientes de escritorio para acceso offline, pero tampoco es algo muy grave, ya que dispone de una API pública, en forma de web-services REST.

La versión de pago añade un organizador al que le indicas el tiempo que tienes disponible y te genera una lista de tareas de acuerdo a dicho tiempo, personalización del booklet, acceso a estadísticas, subtareas, permitir que otros puedan modificar tu lista de tareas, o conexión segura con SSL.

Y pim pum pas, la próxima semana más

(*) A la hora del café por supuesto

XNA GameStudio beta 3.0

2008-09-17T09:39:00.001+02:00

Pues al parecer ya ha salido la beta de XNA GameStudio 3.0.
Entre otras novedades permite usar la versión 3.0 de C#, programar para el Zune, y crear proyectos para la Xbox360 (aunque me parece que la beta aún no permite probar el código en la consola)

Habrá que echarle un vistazo :)