Ya pasé por encima del tema de los concursos en la Euskal, en el post recopilatorio de mi iniciación a la experiencia vital que fue. Ahí animé a cualquiera a probar suerte con los concursos, puesto que debido al limitado número de participantes posibles, todo depende de tu talento y concursar por algo se vuelve algo interesante.

Sí, probé suerte. Concretamente con el concurso de programación de GureGipuzkoa. Sobrevolando un poco el asunto: GureGipuzkoa es un proyecto de la diputación de cultura de Gipuzkoa (si no me equivoco).

Lo cierto es que me esperaba algo más de participación, pero en general no estuvo nada mal. Está publicada la lista de proyectos participantes, los resultados y la entrega de premios, a la que no pude asistir (para mi desgracia a esa hora ya estaba en el tren de vuelta a Madrid). Pero no deja de ser un boost de ego, la verdad .

Mi proyecto consistió en un mashup que cruzaba Google Maps con las fotos del sitio web. Es bastante perfeccionable, puesto que en aquel momento no funcionaba el API para realizar búsquedas geográficas y tuve que recurrir a diversos hacks no demasiado claros para hacer funcionar la aplicación, pero el resultado en general es bastante usable (y debí haber añadido paginación, aunque es muy sencillo).

La versión online está disponible aquí, junto con un video publicado (screencast) que explica el funcionamiento de la aplicación (que ya de por si es muy sencilla y autoexplicativa).

Los premios iniciales consistían en un Reloj Binario, una cámara compacta de alta gama y una aspiradora Roomba. Al final, por temas de stock se quedó en una cámara (modelo distinto, aunque ampliamente superior) junto con una tarjeta de memoria y funda así como la aspiradora Roomba.

Aún no he tenido la ocasión de probar la Roomba (es el problema de vivir en una casa de varias plantas), pero en cualquier caso, la cámara es absolutamente maravillosa. Tuve la ocasión de probarla en un pequeño viaje que hice a Zaragoza con un amigo, las fotos como de costumbre están en un set de Flickr.

La cámara, una Samsung ST-1000, tiene GPS, WiFi así como un zoom óptico bastante alucinante y una calidad de imagen muy buena. Lo único que realmente echo de menos es la posibilidad de sacar fotos en lugares con poca luz sin trípode, pero mucho me temo que para eso no me queda otra que usar una réflex con trípode.

Por cierto, este año vuelvo a estar en la Euskal Encounter (encaja de milagro entre los planes que ya tenía marcados, y allí estaré salvo imprevisto).

La idea es la de tener un objeto principal (maestro) con un constructor que crea dentro del propio objeto tantos objetos “internos” como hagan falta, pasándole por referencia su propio objeto al constuctor de los “objetos internos”.

Los “objetos internos” extienden a una plantilla de objeto, y esa plantilla contiene un constructor que a su vez “guarda” como referencia el parámetro pasado por el objeto principal.

Sí, es un lío, así que mejor verlo en código:

class AppObjectSkel {
  function __construct(&$parent) {
    $this->_parent = $parent;
    if(is_callable(array($this, 'init'))) $this->init();
  }
}

class AppDatabase extends AppObjectSkel {
  function init() {
    /* Aquí se inicializa la DB */
  }
}

class AppCache extends AppObjectSkel {
  /* Elemento de cache, no lo inicializamos en este ejemplo */
}

class Application {
  function __construct() {
    $this->database = new AppDatabase($this);
    $this->cache = new AppCache($this);
  }
}

De esta manera se puede acceder de un elemento a otro. Por ejemplo, desde AppCache se puede acceder a AppDatabase pasando por Application, simplemente usando $this->_parent->database. Al tratarse de un valor pasado por referencia, se puede acceder desde AppDatabase a AppCache y reflejar cambios en tiempo real.

Pero hay que tener en cuenta un pequeño detalle: los constructores. Debido a que se hereda de una clase maestra (AppObjectSkel), no se puede poner constructor de ningún tipo (ya sea __constructor o una función con el nombre de la clase), ya que PHP ejecutará únicamente el del objeto creado (AppCache, por ejemplo) y no el de AppObjectSkel (y mucho menos va a ejecutar dos constructores). Se puede evitar esto de varias formas: evitando AppObjectSkel en todos los casos y copiando el construct a cada vez, copiando el construct sólo cuando lo necesitamos (por que pisamos el construct de AppObjectSkel) o simplemente usar una función opcional (llamada init), como pongo en el ejemplo, que sólo se ejecuta si existe y se llama desde AppObjectSkel, a modo de constructor (un constructor invoca a otro).

Desde la propia aplicación simplemente hay que crear una nueva instancia del objeto Application ($app = new Application) y acceder a los diferentes objetos a partir del maestro ($app->db, $app->cache).

Esto llega a ser muy útil cuando la aplicación entera está divida en objetos (AppUsers, AppForums, AppProfiles...) y es necesario hacer transacciones entre los objetos. En lugar de crear una instancia para cada objeto cada vez que se necesitan (por ejemplo, instanciar AppCache desde AppUsers cuando hace falta usar memcache), se pueden instanciar una sola vez y acceder en un entorno protegido (Application, que vendría a ser un “contenedor” relativamente protegido de variables pisadas y globales erradas), a todos los objetos o variables que haga falta.

Con esto después se pueden hacer montones de cambios (instanciar una clase poco usada sólo cuando se necesita, hacer una especie de namespace para tener un cache durante la ejecución del programa…). Y es que ahí, la imaginación es el límite.