Archivo de la categoría: Desarrollo

Temas relacionados con programación y herramientas de desarrollo.

Transformaciones AST para importar clases de IDL

En la anterior entraba hablaba un poco sobre las transformaciones AST de Groovy y que me maravillaban (y si esto último no lo dije, lo digo ahora). Como me gustan y las veo útiles decidí ponerlas en práctica para un uso real.

En donde trabajo se utiliza un lenguaje de programación llamado IDL. Este lenguaje se utilizan en muchos entornos de investigación y para ser sinceros se haría un favor al mundo amputándole las manos a la persona o personas que lo diseñó/aron (pero dejemos esto para un posible futuro artículo). En IDL se pueden crear funciones y procedimientos o se puede crear clases con métodos y atributos. Cuando se necesita ofrecer a otro lenguaje de las funcionalidades que hemos creado en IDL se hace uso siempre de clases y objetos. Además provee de una herramientas denominada Export Bridge Assistant (EBA) para facilitar la tarea de generar los bindings del lenguaje destino. Debo decir que me EBA hace cierto trabajo por el programador, concretamente genera una clase en java o .Net con los métodos seleccionados, pero en el caso de Java no hace distinción de los tipos de datos. Para él solo existe el JIDLNumber, pero está prohibido por el programador su uso, sino que debes utilizar JIDLFloat, JIDLLong, etc. Además, estos tipos de datos no son nativos de Java lo que supone un sobreesfuerzo para el programador.

En esta situación se me ocurrió crear una transformación AST que generase el código de los métodos usando datos nativos de Java. En lugar de llamar a EBA para generar el binding se crea una clase de esta forma:

1
2
3
4
5
@IDLClass(idlclass="CLASE_DE_IDL")
class MiClaseEnJava extends JIDLObject {
   @IDLFunction(name="FUNCION_IDL")
   float miFuncion(float a, float b, String cadena) {}
}

Durante la compilación de la clase se detecta la nota IDLClass y se pasa el control a la transformación AST que añade un constructor por defecto necesario para los objetos que heredan de JIDLObject. Además se busca de nota IDLFunction y cuando se encuentra se interpretan los parámetros para generar el código con las transformaciones de tipos necesarias.

Sinceramente creo que esto es más óptimo que hacer uso de EBA, ya que de todos modos me termino creando métodos que realizan la transformación de tipos y de este modo me ahorro dicho trabajo.

Lo que más me ha costado es entender como funciona la generación de código ya que se basa en la estructura del compilador. Concretamente me ha constado 1 semana hacer la transformación.

En cuanto pueda publicaré el código para que lo pueda utilizar quien quiera, que seguro que mal no hará.

Haciendo memoria

Esta semana he recordado uno de mis viejos proyectos de cuando era más joven (sería el año 97). En aquel momento tenía en mente la creación de un lenguaje que pudiese ser modificado en tiempo de compilación. Con esto me refiero a que pudiesen crearse reglas que permitieran modificar el cómo este compilaba o añadiese nuevas posibilidades al lenguaje.

En aquel momento yo no tenía conocimiento alguno de lenguajes, gramáticas o compiladores y el único curso que vi fue el de la revista Solo Programadores de varios años atrás y, la verdad, no me resolvió ninguna duda (esto se debe a que entonces no solía leer tanto y miraba solo por encima las cosas).

El caso es que me he encontrado que ya lo han inventado. En Groovy existe una característica denominada transformaciones AST que permite modificar las reglas de compilación.  Debo reconocer que es una característica tan chula como difícil de utilizar (todo hay que decirlo).

En estos momentos me encuentro estudiando la documentación para ponerme a hacer pruebas y comprobar qué tal funciona. La verdad es que permite hacer cosas tan increíbles como Groovy++, que es un optimizador de Groovy (lo que hace es eliminar algunas características de Groovy para acelerar la ejecución de las aplicaciones).

He podido encontrar una gran cantidad de ejemplo y la verdad es que me sorprenden mucho. Por ejemplo se pueden automatizar patrones de diseño con este sistema tal y como se hace con la transformación Bindable. Ésta convierte un atributo de clase en un sistema que permite monitorizar los cambios del mismo (patron ). De este modo si tenemos algo como:

1
2
3
class ClaseDeEjemplo {
    @Bindable String prop
}

Se transformará de forma automática en:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class ClaseDeEjemplo {
    private String prop
    PropertyChangeSupport pcs = new PropertyChangeSupport(this);
    public void addPropertyChangeListener(PropertyChangeListener l) {
        pcs.add(l);
    }
 
    public void removePropertyChangeListener(PropertyChangeListener l) {
        pcs.remove(l);
    }
 
    public String getProp() {
        return prop;
    }
 
    public void setProp(String prop) {
        pcs.firePropertyChanged("prop", this.prop, this.prop = prop);
    }
}

Con lo que evitamos tener que escribir un gran número de líneas de código. Sinceramente me parece un gran avance.

A vueltas con las plantillas

Ando haciendo pruebas últimamente con C++ y hay algo que ahora no soy capaz de hacer, que es que elija entre un método u otro dependiendo de si lo que se le pasa por parámetro es una función o un functor.

Concretamente tengo algo como esto:

template<typename T, typename Proxy = queue_proxy<T> >
class channel
{
public:
	template<typename Result>
	channel<Result, typename Proxy::template bind<Result>::type>
	operator>>(Result (&receiver)(T))
	{
		channel<Result, typename Proxy::template bind<Result>::type> out_channel;
		threads.push_back(new boost::thread(create_stream_channel_thread(*this, out_channel, receiver)));
		return channel<Result, typename Proxy::template bind<Result>::type>(out_channel);
	}
};

La idea es que este código permite hacer algo como lo siguiente:

int fac(int x)
{
	if(x < 1) return 1;
	return x * fac(x-1);
}
 
void show(int x)
{
	std::cout << x << std::endl;
}
 
/* some code here */
 
channel<int> ch;
 
/* Se redirige el canal a fac y la salida del factorial a show */
ch >> fac >> show;
 
/* more code here */

Sí, el código se parece mucho a Axum de Microsoft, que la idea es crear algo parecido para C++.

El caso es que el operador funciona bien cuando se pasan funciones, pero no funciona si le paso un functor, como podría ser el caso siguiente:

class functor
{
public:
	functor() {}
 
	int operator()(int a)
	{
		/* do something interesting */
	}
};
 
/* some code here */
 
channel<int> ch;
ch >> functor() >> show;

La cosa es que no sé como hacer para detectar que se me pasa un functor y qué parametros son los que tiene, aunque aún tengo que hacer alguna prueba más antes de dar por imposible la tarea.

Muchas cosas

Ya hace tiempo que no escribo nada, sobre todo desde que uso Twitter. Pero aún así hay cosas que no va bien ponerlas en dicho servicio.

La primera de todas son mis opiniones sobre la economía. Es curioso como los estados están gastando grandes cantidades de dinero en bancos, industria automovilística y otros para mantener dichos sectores cuando la gente no consume. ¿No sería más lógico darle dicho dinero a los usuarios para que puedan realizar compras?

Lo segundo tiene que ver con la reciente sentencia sobre derechos de autor en la que se ha condenado a un webmaster por hacer uso lucrativo de descargas en internet. En este sentido me he dado cuenta que la SGAE (y otras) hace un uso lucrativo de dichas descargas gracias a la retribución por compensación de copia (el canon). Dicho de otro modo, ellos se lucran por las descargas de internet más incluso que las mafias del top manta (no tengo datos de esto, pero como ellos se los inventan, yo también).

Por último, y ya fuera de este ámbito, he estado viendo algunas cosillas de C++ que molan. El profesor Daniel nos comentó en clase sobre la plantilla future de las bibliotecas Boost C++ y me dio por implementarla yo para ver como debía funcionar. Está super chulo, ya escribiré algo sobre eso más delante.

Plantillas en C++

Recuerdo cuando empecé a aprender C++ que la cosa que menos entendía era el uso de plantillas. Debo reconocer que me ha costado mucho comprender como funciona porque era algo completamente diferente a lo que hasta entonces había visto.

Por otro lado, hemos visto en los últimos tiempos como gran cantidad de arquitecturas han copiado el modelo para implementarlo a su modo. Aquí es donde vemos los genéricos de Java y de .Net. El problema es que no tienen ni de cerca la misma potencia que el sistema de C++, pero que como ventaja consumen menos espacio de ejecutable.

Para entrar un poco en materia, comentar que las plantillas de C++ son como documentos en los que dejamos lineas en blanco y luego las rellenamos cuando ya sabemos qué queremos poner en ahí. Pero en C++ no ha líneas en blanco, estas tienen nombre.

La principal ventaja de este sistema es que permite programar clases genéricas, como pueda ser una clase lista que automáticamente se adapte al tipo que debe contener. La segunda ventaja es el rendimiento, por el mismo motivo anterior.

Para empezar a ver un poco como va la cosa vamos a ver un ejemplo sencillo de plantilla:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
template<typename T, int S>
class array
{
private:
   T *ptr;
 
public:
   array()
   {
      ptr = new T[S];
   }
 
   T& operator[](int idx)
   {
      return T[idx];
   }
 
   int size()
   {
      return S;
   }
};
//</typename>

Como vemos, hemos utilizado la palabra reservada template para indicar que se trata de una plantilla y luego, entre los símbolos < y > hemos introducido la lista de elementos de la plantilla. Estos elementos son los tipos y nombres de los valores a sustituir. En este caso son T de tipo typename y S de tipo int. Esto significa que cada vez que dentro de la clase aparezca T deberá sustituirse por su corresponditente valor pasado en la plantilla y que necesariamente deberá ser un tipo de dato (por ejemplo un int, una clase, etc.) y que cada vez que aparezca S deberá sustituirse por su valor que deberá ser un número entero. Para utilizar la plantilla sólo deberemos hacer lo siguiente:

1
2
3
4
5
6
7
8
9
10
int main(void)
{
   using namespace std;
 
   array<int , 5> a;
   cout < < "Tamaño del array: " << a.size() << endl;
   a[1] = 5;
 
   return 0;
}

Como vemos, lo único que hemos hecho ha sido añadir al nombre del la clase la lista de argumentos. En este caso concreto, deberá devolver que el tamaño es 5, que es el indicado en el parámetro de la plantilla.

Si nos fijamos en bibliotecas como STL o Boost, hacen un uso intensivo de las plantillas. El principal motivo es que C++ está optimizado para funcionar con plantillas, así que se prefieren al uso de mecanismos como la herencia. Además, la herencia hace que las llamadas a métodos sean más lentos, por lo que también se evita. Es en este momento cuando nos podemos preguntar el cómo hace C++ entonces para garantizar que se implementan ciertas funcionalidades. Por ejemplo, si queremos tener una lista ordenada, nos interesa que los elementos de la lista puedan compararse entre ellos con el operador <=. Pues la respuesta es sencilla: en la clase de plantilla simplemente utilizamos ese método y en tiempo de compilación se comprueba si está o no. Por ejemplo:

1
2
3
4
5
6
template<typename T>
T& mayor(T& a, T& b)
{
   return a >= b ? a : b;
}
//</typename>

Hemos creado una función mayor que devuelve el mayor de dos elementos de tipo T. Los elementos de tipo T deben sobrecargar el operador >= para que funcione. Como se ve, no es necesario hacer herencia de ningún tipo, el compilador detecta automáticamente si está o no sobrecargado y dará el correspondiente error en caso necesario (si miramos el caso de Java o de .Net veremos como sí es necesario hacer herencia para que el mecanismo de genéricos funcione de este modo).

Debo decir que el tema de las plantillas está muy bien y se puede hacer muchas cosas interesantes, como la clase array, que funciona igual que un array y que tiene un rendimiento muy parecido (benditos métodos inline de C++).

Otro día, seguiré hablando sobre plantillas, que dan para mucho.

Aprendiendo Grails

La verdad es que últimamente me encuentro algo perro y escribo poco en la bitácora, lo cual no me molestaría lo más mínimo si no fuera porque casi cada día se me ocurre algo que escribir en ella.

Una de estas cosas que me están ocurriendo actualmente es que estoy aprendiendo a programar en Groovy para utilizarlo junto a Grails. ¿Y qué serán estos “insultos” que acabo de soltar? Pues Grails es un conjunto de herramientas que busca ayudar a hacer aplicaciones web de forma rápida gracias al uso de convenciones. Para los que sepan un poco de qué va todo esto, es una copia de Ruby on Rails (RoR, de aquí en adelante), pero utilizando herramientas Java.

El caso es que no lo he elegido frente a RoR por ser mejor que este ni más bonito. Lo he elegido porque tiene buena compatibilidad con Java y así puedo aprovechar cosas que ya tenía desarrolladas en este otro lenguaje (ahorrándome tiempo de desarrollo).

Ahora estoy haciendo una aplicación para la beca. No será muy compleja y me servirá para comprobar como funciona esta arquitectura. De momento las pruebas son realmente prometedoras :)

Diseño UML

Hasta hace poco andaba buscando una herramienta de diseño UML que fuese portable, pudiese generar ficheros XMI y, como no, que me gustase. Después de mucho buscar he encontrado ArgoUML.

Dispone de todo lo necesario:

  • Diagramas de clases, interacción, despliegue, etc.
  • Exportar a XMI e imágenes.
  • Importar a partir de código fuente (Java, C++, IDL).
  • Generador de código (Java, C++, C#, PHP5, etc.).
  • Check lists para comprobar si se están definiendo adecuadamente las clases.

Ahora me toca probarlo más en profundidad a ver qué tal, pero tiene muy buena pinta. Hay algunas cosillas que podrían ser más simples y estaría bien que los tipos de datos fuesen configurables ya que utiliza los de Java por defecto.

A ver si un poco más adelante puedo hacer una reseña más completa sobre la herramienta.

Java reflection y los tipos genéricos (y II)

Después de mucho pegarme con esto conseguí que me funcionase. Debo decir que no me gusta nada el hecho de no poder saber el tipo con el que se ha creado un genérico.

Para que se comprenda qué es lo que he hecho y para qué lo necesitba tengo que decir que en la beca tengo una aplicación realizada en C++ que tiene impletentado su propio tipo de seriado (La palabra en español para serializar es seriado. Como en C++ no hay mecanismos de introspección (como java reflection, system.reflection, etc.), el modo de hacerlo es un poco más feo.

Seriado en C++

El mecanismo de seriado que he utilizado en C++ ha consistido en crear una clase abstracta con dos métodos abstractos, uno se seria los datos a un canal (puede ser un fichero, la red, MPI, etc.) y otro que realiza la operación inversa:

/**
* Clase abstracta que define los dos métodos necesarios para poder
* seriar cualquier clase por un canal de almacenamiento o de
* comunicaciones.
*/
class Serializable {
   /**
   * Seria el objeto a través de flujo os.
   */
   void writeObject(OutputStream &os) = 0;
   /**
   * Lee los datos del objeto desde el flujo is.
   */
   void readObject(InputStream &is) = 0;
};

Es importante hacer notar que cualquier mecanismo de seriado exige que la clase seriable tenga un constructor vacío, para permitir regenerar todos los datos a partir del mecanismo de seriado.

El problema del mecanismo anterior es que el programador debe saber qué es lo que se va a transmitir y, por tanto, sabe qué tipo de dato le va a llegar. Esto no sucede con el sistema de seriado de java, que transmite el tipo de dato a través del canal.

Cuando quise ponerme a realizar esto mismo en java pensé que si ya tenía un mecanismo que me decía qué era lo que tenía que leer, no sería necesario implementar readObject y writeObject en cada clase, ya que puedo consultar cuales son los atributos de la clase. Pero el problema sobrevino cuando llegaron los genéricos.

Los genéricos en Java

Los genéricos en Java funcionan igual que las plantillas de C++, pero con una salvedad. En C++ las plantillas se transforman en una implementación distinta para cada tipo con el que se generase la plantilla, en Java sólo existe una implementación con el tipo más simple de la plantilla (si no se especifica nada, es Object).

Lo anterior significa que si yo tengo un vector de simulaciones, en C++ se creará una implemtanción específica de vector que sólo trabaja con simulaciones (y ningún otro tipo). En Java no sucede lo mismo. En Java sólo hay una implementación que será de tipo Object (todos heredan de Object) pero el control de que sea una simulación se realiza en tiempo de compilación. Esto supone que cuando se ejecute la aplicación ya no conoce si es correcto el dato que se le está pasando, ha sido el compilador el que hico la comprobación. Esto supone que no puedo regenerar de la forma deseada el vector.

Solución actual

En estos momentos he conseguido que funcione. Lo primero que hice fue ponerlo todo igual que lo tenía en C++, pero en Java. De este modo, todas las clases seriables deberán tener un readObject y un writeObject. Y para solucionar el tema de los genéricos hice lo siguiente:

Cree el tipo vector genérico que es seriable por este mecanismo. Para garantizar que funcionará he formazado a la clase a ser abstracta. Con lo que comenté en la anterior entrada sobre cómo obtener el tipo genérico, que dije que no funcionaba, pues sí funciona, pero no como yo esperaba. Para que funcione hay que heredar de la clase genérica de este modo:

abstract class VectorSeriable {
   void readObject(InputStream is) {
   /* Leo utilizando el tipo del generíco como se dijo en la anterior entrada */
   }
   void writeObject(OutputStream os) {
   /* Grabo los objetos */
   }
}
 
/**
* Al heredar de este modo, estamos creando una clase VectorSimulaciones
* que es idéntica a VectorSerializable, pero que ya conoce cual es el tipo
* de su genérico.
*/
class VectorSimulaciones extends VectorSeriable {}

Como se puede apreciar, esto es igual que utilizat typedef en C++. De este modo he conseguido que funcione. Ahora debería ser posible eliminar los metodos readObject y writeObject para automatizar todo ya que es bastante feo tenerlos en cada clase.

Java reflection y los tipos genéricos

Por temas del trabajo llevo unos días pegandome con java reflection y los tipos de genéricos. Debo reconocer que las dos cosas están muy bien, pero entre ellas no se llevan bien. Para facilitar un poco la cosa voy a poner un ejemplo de un tipo genérico:

1
2
3
4
5
6
7
8
9
10
11
12
public class Lista<tipo> {
   /* para evitar problemas con wordpress: </tipo> */
   tipo leeElementoEnPosicion(int posicion) {
      tipo rtn = null;
      /* Buscamos el elemento y lo devolvemos */
      return rtn;
   }
 
   void agregarElemento(TipoElemento elm) {
      /* Insertamos el elemento */
   }
}

El código anterior no hace nada, pero nos permite ver que creamos una clase Lista que es genérica. El hecho de que sea genérica significa que podemos decir que la lista podrá almacenar cualquier tipo de dato y que se lo indicaremo al crearla (antiguamente en java sólo se podía almacenar un tipo de dato: Object).

Mi problema empieza cuando yo necesito desde una instancia de la clase Lista cuál es el tipo de dato que almacena. Inicialmente sería tan sencillo como hace lo siguiente:

public Class leerTipoElementoLista() {
   return tipo.class;
}

El problema es que, según parece, en la práctica java no utiliza genéricos, sino que sólo los comprueba en tiempo de compilación. Esto significa que una vez compilado el programa, tipo deja de ser un tipo conocido y pasa a ser algo completamente indeterminado, o dicho de otro modo, se convierte en un Object. A causa de esto, la sentencia anterior (tipo.class) genera un error de compilación.

Buscando por el gran Google encontré una referencia a Hibernate donde comentaban un modo de hacerlo:

(Class) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];

Lo he estado probando y lo único que puedo decir es que falla en la ejecución. La sentencia anterior genera una CastException, así que nada.

Y yo necesito poder saber el tipo del genérico :'(

Jugando con Apache Tomcat

Hace poco me dio por instalarme tomcat en el ordenador. ¿Por qué? Pues porque me parece que desarrollar webs con java es más seguro que hacerlo con PHP… lo que no tiene porqué ser cierto, pero me gusta más la arquitectura de java (aunque no su rendimiento).

El caso es que me animé más con las clases de Servidores de Información, donde trasteamos también con tomcat. Ahora me rondan varias cosas por la cabeza para realizar, entre ellas un sistema para jugar a rol, que no me gusta nada, pero nada, hacerlo por foro, no están preparados para estas cosas. Además, hay que saber un poco de todo ¿no?

A ver si me pongo y me miro la charle de Mariscal sobre AJAX, que también estoy muy interesado en aplicarlo ^^