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.

Aquí viene una solución que he encontrado buscando y que me ha funcionado con el último firmware (2.2.1). Basta con tener el iPhone 3G jailbreakeado, Cydia instalado, actualizado y cinco minutos libres. El proceso es sencillo:

1. Abres Cydia.
2. En la ‘pestaña’ o ventana “Home”, seleccionas “More package sources”, justo debajo de “Featured packages”.
3. En la lista buscas el repo llamado “iPhone-Notes.de”.
4. Pinchas, confirmas, le das a instalar, aceptas todo y vuelves a la pantalla de Cydia.
5. En la lista de secciones verás un par de nuevas secciones. El paquete está en “Tweaks (2.2)”.
6. Dentro de la sección “Tweaks (2.2)” hay un paquete llamado “ForwardMsgFix”.
7. Tocas sobre el paquete, confirmas, instalas y sales de Cydia.
8. Apagas el iPhone por completo (apretas en el botón power durante unos segundos, deslizas la barra ‘Apagar’ y esperas a que se apague completamente – puede tardar un rato).
9. Vuelves a encender de la misma forma, apretando el botón de power. Lo que se dice reiniciar, vamos.
10. Voilà!

Todo sea por encajar una chorrada en 10 pasos, pero vamos. Estoy feliz, ya puedo cancelar alegremente esas llamadas fatídicas de errores de toque. Y torpeza, claro.

OVH es una empresa de alojamiento web Europa. Dispone de peerings propios en España, Francia, Italia, Inglaterra, Bruselas, Holanda, Alemania, Polonia, República Checa, Austria, Suiza, y otros peerings en IX independientes (por ejemplo PAIX, que es el punto de intercambio neutro situado en Nueva York). Además, tienen tránsito con las grandes empresas que manejan el flujo de datos en Internet: Level3, Global Crossing o TeleGlobe por ejemplo.

En resumidas cuentas significa que por un lado han establecido fibras hasta los intercambios de cada país que he expuesto por arriba. Y en cada uno tienen un router, que conectan con los diferentes operadores de cada país. Y donde no llegan, pasan a través de las empresas de tránsito que son las que llegan donde su propia red no llega (extranjero sobre todo).

OVH instaló hace poco su fibra y router en ESPANIX, desde Francia. Desde Paris hasta Madrid hay una latencia de 16ms, y tienen 2×10Gbps, es decir, 20Gbps de conectividad. Normalmente deberían establecer conectividad con todos los operadores españoles. Hacerlo bien significaría baja latencia desde España hasta los servidores de OVH y una velocidad bastante alta.

Como he expuesto arriba, Telefónica requiere un tráfico de al menos 6 Gbps para hacer peering. OVH de sobra genera ese tráfico ¿por qué no hacen peering? Si miráis el gráfico de arriba la latencia se dispara y en los gráficos de tráfico se encuentra un tope de 4 Gbps. ¿Significado? Está limitado el tráfico a 4 Gbps, y la conexión se satura en el tránsito con Telefónica, siempre desde la red OVH.

Por lo tanto, como limitación encubierta a OVH, Telefónica ha limitado su tránsito para evitar hacer peering. Esto hace que todos aquellos que tenemos servidores en OVH y necesitamos buena latencia y velocidad (ficheros/servidores de juego), estemos limitados a una conexión pésima desde Telefónica.

Larga vida a OVH, larga vida a los operadores alternativos y al libre tránsito de datos.

» Leer email envíado por OVH a sus clientes