Archive for the 'Enredando' Category

Objetos maestros en PHP

Ya comenté el tema de usar clases “principales” para un proyecto… y ahora vuelvo con el mismo tema. Muy creativo, sí…

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.

Actualizando

Llevo una eternidad sin escribir en este blog y ya va siendo hora de ponerse al día. Me niego a estar más de un mes sin escribir (y por los pelos). Además, tengo un caos mental impresionante… pero allá vamos.

Han, he, cambiado un montón de cosas. Como no quiero estancarme en lo personal, simplemente diré que los tiempos cambian, Murphy me sigue puteando (maldito mal tiempo). Ah, y cuando unos nacen otros mueren (va en serio). Oh, y sí, me muero de sueño y me pica un ojo (momento Juankiblog).

Al grano. Voy por orden y enumerando los proyectos, para decir qué cambia y qué no (vale, sólo lo que cambia, vale):

Linkloo: Un pequeño “tumblelog” de información sobre el servicio. Arriba del todo, los antiguos “Canales” renovados. Por ahora son poco precisos pero voy a ir mejorándolos con el tiempo. También hay un montón de parcheos (bugfixes). Montones, cientos, a saco (si Feedburner/Google me putea –cambia la ubicación de los feeds–, yo el doble –y soy cabrón–). La idea es que este proyecto “automantenga”: evitar que se atasque controlando todo a muy bajo nivel, separando las operaciones y “vigilando” todo un poco mediante un sistema (sencillísimo) de procesos. Y lo que falló fue eso, se atascó y tardé una parte de la eternidad en darme cuenta y parte de la otra en saber qué fallaba. Pero bueno, no debería a volver a dar problemas.

fileSpawn: Hace tiempo que migré la infraestructura a Lighttpd y no me arrepiento. Más bien lo contrario. Ahora mismo estoy limitando la velocidad por descarga por usuario y en este momento (baja actividad –20h de la tarde–, últimamente está todo de bajón) envía a unos 5500 kB/s (50 Mbps) o un 25% de la capacidad (65 usuarios únicos ahora mismo, aunque llega hasta 300-350 sin despeinarse). Lo que antes era una carga por servidor de 5-10 puntos (y que se vaya a tomar por saco en hora punta) ahora no pasa de 1.50-2 –y eso cuando está cargado– (pero lo mejor de todo es que funciona siempre, no como antes). Va a ser que Lighttpd es genial, sí. Por lo demás: hay un “tumblelog” de información (también) y (¡por fin!) registro de usuarios (interesante sobre todo para guardar los nuevos archivos subidos).

- aquícerca: Estoy pensando como hacerlo aún más útil. Y sigo acordándome de la madre de los programadores de Apple –todos–, hay que ver las que se trae la maldita SDK para apps nativas. Por eso se sobreentiende que sigo programando para web (insertar chiste sobre casinos y furcías aquí). Y lo que toca anunciar: versión básica. Bastante más rápida que la completa, sólo que no usa AJAX ni JavaScript, y por lo tanto tampoco tiene soporte para mapas. Funciona perfectamente en el iPhone (y es más rápida que la otra, con sus carencias y diferencias) pero ahora funciona también en otros móviles (Nokia, Sony Ericsson…) sin problemas. El próximo objetivo es hacer una versión iPhone aún más rápida (¡mucho más rápida!).

Estoy convencido de que me dejo algo, así que esto se queda como “primera entrega”. Pero eso no significa que me vaya sin mencionar al ego (oh, mi querido ego): he “renovado” (y una mierda)  la home de este saco (va a ser “he puesto”, no creo que lo otro se mereciese el término de home). Es un fusilamiento en toda regla de Netvibes, un buen ejemplo para la definición de algo así como “no tener nada que hacer”.

Maldito “Desvío de llamadas activado”

Ni un mes llevo con el iPhone y ya estoy cansado de las ventanitas de “Desvió de llamadas activado”. Al llamar a alguien –por error o no– te tragas la ventana, con todo el rollo de tener que “Aceptar” la alerta antes de poder colgar rápidamente. Vamos, un gran fallo.

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.

Mejorando lo mejorable

- Mejorando aquícerca (aquicerca.mobi), presentado por aquí

Por una parte, ‘detalles’: el CSS y el JavaScript ahora están comprimidos, asi que se debería notar cierta mejoría, sobre todo al usarlo con GPRS/3G, aunque –pese a todo– las librerías de Google Maps son muy pesadas (necesarias aunque sólo use una ínfima parte –el geocoder–). La salida de AJAX, por cierto, está comprimida por GZIP y pasa por un buffer, así que se queda menos ‘pillado’ cuando se busca un lugar. Y ya no es necesario hacer scroll para ocultar la barra de direcciones, puesto que se oculta automágicamente cuando no es necesaria.

Y en cuanto a lo importante: al ver los resultados, hay un icono de teléfono delante del nombre del lugar y un icono de mapa delante de la calle. Si es posible mostrar un mapa, la calle se vuelve ‘clicable’ y el icono de mapa está a todo color. Si está disponible el número de teléfono del lugar, se puede pinchar encima del nombre y el iPhone preguntará si se desea llamar. Sin embargo, cuando no es posible llamar o ver el mapa, los iconos se transparentan (y no hay enlace).

Luego, la otra novedad, y la más gorda: mapas, mapas, mapas. Aunque tampoco es un misterio… Al pinchar encima de la calle se muestra un callejero de Google Maps adaptado para móviles. Está preparado para ocupar toda la pantalla –ocultando la barra de direcciones– y cambia de orientación al girar el teléfono. Y tiene una imagen de carga muy clásica (plan AJAX). Luego, lo obvio: dos globitos. Uno rojo que indica la posición del usuario y uno verde que indica la posición del lugar seleccionado. Y para cerrar, basta con tocar el mapa.

Aquí cerca

Lo comenté en el post ‘A muerte con el mapa‘. Y la idea era bastante sencilla: traducir una ubicación a posición geográfica (reverse geocoding, que era uno de los temas que traté) y después buscar –por texto libre– cerca de esa ubicación.

Pues bien: se llama ‘aquícerca‘ (aquicerca.mobi) y está diseñado para usarse desde un iPhone/iPod Touch, sobre todo para cuando se está en movimiento (por ejemplo, cafés cerca de la parada de Metro en la que me encuentro). Cierto que para el iPhone ya existe Google Maps (y con el GPS!), pero en este caso uso el API de 11870.com que a mi parecer es bastante mejor… o lo prefiero.

Del lado técnico: usa el API de 11870, el API de Google Maps, MagpieRSS para parsear la salida del API de 11870 (no sé por qué pero SimpleXML se volvía tonto al parsear la salida RSS del API de 11870, era imposible conseguir los atributos geográficos o la calle), jQuery para la interacción con el usuaro (AJAX, bloqueo de formularios, transiciones entre páginas) y PHP del lado servidor (se limita a recibir la respuesta del Geocoder –que se ejecuta del lado del cliente, para evitar el capado de queries que tiene esta parte de Google Maps–, genera los formularios y devuelve los resultados de la búsqueda en 11870.com).

Como el navegador del iPhone de por sí es lentorro, está casi todo en AJAX para evitar cargar nuevas páginas. Por lo tanto, incluso para volver al estado inicial (tocando el logo) no se vuelve a pedir la página, simplemente se restaura por medio de JavaScript –y con unas transiciones mu chulas, hay que decirlo–.

Pese a que no hay ningún mapa que se muestre, usa el API de Google Maps para los módulos de geocoding, como comentaba en otro post. Se hace todo por medio de JavaScript (lo que inicialmente pensaba hacer del lado del servidor), y la verdad es que es bastante más rápido que procesar todo por PHP, sobre todo cuando se trata de enviar y recibir datos por 3G.

Mientras tanto, Miquel (gafeman) ha sacado su versión móvil para comil.us (lo comenta por aquí). La versión móvil suya es bastante más completa: usa Static Maps e incluye las fotos, aunque está limitado a unas búsquedas predefinidas (y saber a qué distancia estás del lugar) pero el mapa es una gran idea (y creo que en mi caso tampoco estaría mal tener un mapa del tipo “estás aquí, el lugar tal está aquí”). Y bueno, también por si quieres más de 5 posibilidades, claro (seguimos hablando de versiones móviles…).

La aplicación está preparada para usarse tanto en vertical como en horizontal (chorrada obvia) pero se maneja muy bien en vertical (no pierdes libertad de movimientos, con el pulgar va bien). Se puede añadir a la pantalla principal del iPhone/iPod touch apretando el botón inferior de + y seleccionando “Añadir a pantalla de inicio”, y ‘automágicamente’ aparecerá una bonita taza de café en vuestra lista de aplicaciones.

Por cierto, sí, el diseño: es CSS muy sencillo (a la par de cutre), el icono proviene de un maravilloso set de 128 iconos de WeFunction. Merece darse una vuelta por su blog, tienen trabajos incréibles.

La tipografía del título es la Alte Haas Grotesk, una sans-serif bastante agradable a la vista.

Asi que si tienes un iPhone o un iPod touch, ¿por qué no probarlo?, si hasta puede que te quede espacio en la pantalla principal para poner la bonita taza de café de aquícerca.mobi :-) .

Batallitas de Telefónica y OVH: Limitando el tráfico

Si eres una empresa de tránsito IP o dispones de una red de servidores, y quieres hacer peering directo con Telefónica tienes que tener un tráfico de unos 6 Gigabits por segundo, o lo que vienen a ser sobre los 700 Megabytes por segundo (o un CD enterito cada segundo!).

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