/dev/GON.clblog respaldo anti-amnesia

Hace algunos días por alguna extraña alineación planetaria, tuve problemas usando kopete, por lo cual… debí recurrir a la otra opción más a mano, pero del lado oscuro: pidgin.

Pero gracias a ese incidente, me topé con un par de cosas interesantes. La primera es que terceros desarrollaron un plugin para pidgin, que permite usar el chat de Facebook dentro de él. El paquete está disponible a través de un repositorio de Google Code.

Ya había visto la noticia sobre un plugin similar que estaba cocinando Duncan Mac-Vicar para Kopete, pero no le vi mayor interés hasta ahora, que ya había probado el de pidgin.

Durante la semana pasada, baje y compilé las fuentes (y sus dependencias) para probar. Así pude testear el funcionamiento del plugin. Por desgracia aun está muy inmaduro, pero ello no lo hace menos interesante.

Una de las dependencias kopete-facebook es qjson, una librería que extiende Qt para añadirle un JSON Parser, necesario para procesar los datos recibidos/enviados por la red de facebook.

Lamentablemente, ni kopete-facebook ni qjson estan empaquetados en ubuntu jaunty (qjson está en 9.10 karmic koala, pero karmic aun está en estado alpha). Tanto Duncan[1] como Flavio[2], solo ofrecen los paquetes fuente y un paquete para opensuse.

Entonces, luego que logré compilar ambas librerías se me cruzó por la cabeza…“Cualquiera puede hacerse un PPA, ¿y si lo empaqueto para kubuntu y lo subo?” Bueno, a eso me dediqué este fin de semana.
Leer el resto de esta entrada »

Mientras trabaja por volver a levantar un sitio que antiguamente usaba joomla 1.0, tuve un pequeña molestia en el panel de control del nuevo 1.5, debido a que me salía un mensaje de error.

Afortunadamente no era fatal, ya que igualmente podía modificar los parámetros del sitio sin mayor inconveniente. Pero es molesto ver que algo no está bien, menos en un sistema grande como lo es Joomla.

El error me indicaba que había un archivo XML que no se estaba “parseando” adecuadamente, pero no me decía cual archivo ni cual error tenía.

Entonces decidí bajar una copia de seguridad del sitio completo, y replicarlo en mi máquina local para averiguar el error. Recordé que en linux existen miles de aplicaciones por consola, lo suficientemente poderosas para parsear y validar los XML’s de mi sitio.

Ya tuve una experiencia grata con el comando find. Pero me faltaba el comando para validar un archivo xml. Buscando encontré que posiblemente el comando xmllint me podría servir. Aunque finalmente no me ayudó, revelé un pequeño detalle que no me esperaba.

xmllint tiene una opción para validar, pero para realizar ese trabajo, requiere que 1) el archivo XML defina un DTD o 2) se le pase por parámetro. Probando sin usar un DTD por parámetro: probé lo siguiente:

find . -name "*.xml" -exec xmllint --noout --valid "{}" \;

Lamentablemente, el resultado no fue lo que esperaba. TODOS los XML salvo uno, eran inválidos, debido a que NO TENÍAN definido el DTD. Gracias a ese archivo que sí lo tenía, descubrí que joomla TIENE en su sitio un archivo DTD para que los desarrolladores lo incluyan en sus XML de configuración. De esta forma, el desarrollador obliga a que sus archivos XML tengan la estructura que el sistema requiere.

Lo peor… ese único archivo válido, era de un plugin de terceros y no de los desarrolladores oficiales. Es decir, los desarrolladores oficiales de joomla NO RESPETAN sus propias reglas al escribir el código.

Finalmente, xmllint no era lo que estaba buscando, ya que solo debía comprobar cual era el o los archivos mal formados (etiquetas mal cerradas, mal anidadas, …). Como no sabía, consulte en una lista de correo (una de las que tengo en la lista de comunidades), donde me dieron la solución: xmlwf.

Simplemente cambié el comando anterior por el siguiente y asunto arreglado:

find . -name "*.xml" -exec xmlwf "{}" \;

Encontré los culpables (eran 2), los corregí y di por terminado el asunto.
Pero me quedé con el sabor amargo de la despreocupación que los desarrolladores de Joomla han tenido en un detalle tan simple. ¿Que confianza me dan para cuando aparezca una nueva actualización del sistema?

Mirar código ajeno por primera vez, es como un arqueólogo encontrando una civilización perdida.

A menos que contemos con una piedra rosseta (o mejor aún, conozcamos el lenguaje perdido), la única forma de decodificarlo es “al tanteo”.

Los últimos días, había experimentado una falla inusual en mi aplicación lectora de huellas. A veces guardando el “template” de la huella en la base de datos, quería guardar una segunda o tercera lectura, pero se seguía guardando el primero. Además, solo me identificaba 1 huella de todas las guardadas.

Volviendo al ejemplo que venía junto al kit de desarrollo, encontré el motivo, tanto del fallo como de mi confusión.

Mientras desarrollaba el código del lector de huellas en C#, encontré un método trabajaba con la base de datos, pero en un lugar donde no debía. Lo primero que hice hace meses, fue separar esa porción de código a otro archivo qu corresponde a mi capa de “Modelo”. La linea de la discordia fue la siguiente:

public int identify(ref int score, ref AxGrFingerXLib.AxGrFingerXCtrl grfingerx)
{
    GRConstants result;
    int id;
    SqlDataReader rs;
    TTemplate tptRef; // <= EL FALLO ESTA ACA
 
    // M&aacute;s c&oacute;digo...
}

El encabezado del método tenía un comentario que decía algo así como “compara el template de la lectura con todos los templates obtenidos desde la base de datos”. Por lo tanto, asumí que “TTemplate tptRef” significaba “Huella de referencia”. No sé que concepto de “medida de referencia” tuvo el programador del ejemplo, pero para mí, una regla o un peso es una unidad de medida de referencia. Es decir “Mi template se compara con todos los tuyos”.

Sin embargo, para el programador del ejemplo, “Huella de referencia” significaba “cada uno de los templates de la base de datos”. Es decir, “Mi template en cada vuelta del ciclo, será el mismo de la base de datos y se comparará con tu lectura”.

Ese simple cambio de significado, me echó a perder el código. Ahora después de mucho tiempo de haber hecho esos cambios, logré entender el funcionamiento de ese método solo leyendo el código, pero de no haber usado como “medida de referencia” el código del ejemplo sin modificar, me habría visto obligado a investigar a fondo “donde se quedaba pegado en la lectura de la huella”.

La moraleja es entonces, fijarse en todas las interpretaciones que pueda tener la documentación o los comentarios. Si somos nosotros los que documentamos, debemos evitar que un detalle tan pequeño pueda cambiarle todo el sentido.

Y lo chistoso no fue el peso.

Continuando con el retrasado proyecto del lector de huellas para el control de acceso, me topé con un problema de aquellos…

La aplicación actual de control de acceso funciona con SQL Server 7 sobre Windows 2000, una reliquia mal viviente. La herramienta de manejo de la base de datos (SQL Management) asociada a esa versión, es un verdadero misterio en funcionalidades. Por alguna razón, “Generar consultas SQL” a una base de datos, solo genera los modelos de las tablas, pero ni rastro de los registros. Finalmente no logré sacar esos datos, porque desde generar una copia de seguridad hasta volcar todo a un archivo de texto plano, generaba un lindo “error desconocido”.

No se quien lo logró, pero hoy recibí un DVD con los 900MB de tablas y registros de esas bases. El archivo era un copia de seguridad respaldo.bkp.

Lo primero que hice, fue tratar de jugar con él :p .

Disculpa, pero esta entrada está disponible sólo en English.

Ya que tengo espacio, hay que aprovecharlo.

Un lugar donde explicar las cosas

Mientras no tengo un módulo de para blogear funcional en Gonium, no me queda otra que usar al enemigo (Wordpress). Lo cual no es del todo malo, sino justamente lo contrario.

La idea de tener un blog exclusivamente para el desarrollo de Gonium, me permitirá poder dejar en claro cuales son las ideas que se están implementando o se desarrollaran a futuro, allá en su propio lugar. Hay mucho por hacer, por lo tanto, mantener una bitácora de desarrollo (más que un precario Roadmap), espero me sirva mucho más.

Un detalle importante: el blog, el proyecto en Google en Code, los mensajes en Twitter, los commits de svn e incluso la documentación autogenerada del API, se mantendrán todos en idioma inglés principalmente.

La razón de esto es muy sencilla: universalidad. Aunque no me gusta la idea, lamentablemente en comunicaciones, el inglés es lo más universal. No por ser de origen chileno quisiera que solo algún amigo mío de acá lo ocupe. Espero que a todo a quien le sirva tenga la posibilidad de ocuparlo. ¿Quien me dice que alguien por ahí no estará ya husmeando el código? ¿Y si este alguien hablara en italiano? ¿O francés? ¿o alemán? ¿o chino?

Además, habiendo tenido experiencia en el proyecto GDT, noté como muchos usuarios, aun cuando en su mayoría se trataba de hispano-parlantes, simplemente no les gustó la idea de usar objetos y métodos nombrados en español. No entiendo estas mañas, pero se que son frecuentes y extendidas. De hecho, Eduardo Silva, en su charla de Monkey HTTP Daemon en el Encuentro Linux, mencionó haber tenido ese problema con los hispano-parlantes, así que decidió simplemente dejar todo, lista de correo, blog, documentación, etc, en inglés. Esta vez, adoptaré la misma idea y veré que sucede.

Por el momento, no espero una explosión de usuarios, ni mucho menos mientras la versión funcional brilla por su ausencia, pero sí espero ideas, comentarios y en general feedback. Ya me han estado preguntando cosas como “¿estás reclutando gente?”, lo cual es un alivio para esos minutos en que me cuestiono el “¿para que diablos estoy haciendo algo que solo me importa a mí?”. Por si acaso, sí estoy reclutando gente :B . ¿Desarrolladores en Zend Framework? Bienvenidos! Cualquier tipo de aporte será igualmente bien recibido, ya sea de parte de un PHPero, jQuerysta, CSSero, Traductor, Diseñador o Artísta son plenamente bienvenidos.

Leer el resto de esta entrada »

Los últimos días los he dedicado al estudio de uno de esos viejos problemas que nunca había podido resolver.

Consiste en el almacenamiento “seguro” de datos que viajan en un canal inseguro y se almacenan en un medio inseguro. Puntualmente, hablo de COOKIES. Cuando hablamos de protocolo HTTP(S), las cookies son el único “repositorio de datos” o almacenamiento persistente en el lado del cliente (navegador) con el que podemos trabajar.

En las cookies, podemos guardar las preferencias de un usuario (por ejemplo, el idioma que escoja, la última página que vió, etc…). Y el problema puntual con cookies: guardar la identidad del usuario para “recordar” su sesión.

El peligro esta en el como se guarda esta identidad. Lo bueno es que ya encontré un método que me convenció, y realmente es bastante “simple” como algoritmo. Lo que no fue simple fue la implementación.

La verdad es que no se como pretendía completar el primer punto de mi roadmap (Lista de control de acceso o ACL) sin tener primero un método decente de autenticación. Al menos ya di con una respuesta.

Leer el resto de esta entrada »

Talla(*) para webmasters:

(*) Talla (español chilensis): dícese de broma o humorada

Gracias a la wena onda de Tecnoman, que se auspicio con hosting y me dejo hincharle las pelotas para que instalara PDO en un servidor en producción, tengo el demo de Gonium en un hosting nuevo. Ahora intentaré de algún modo recompensar aquello, posteando más seguido en tecnosquad.org.

Aprovechando eso, subí una copia más reciente.

Hace unos días agregué al trunk del repositorio, una copia propia del proyecto zend-framework-datagrid, con la diferencia de que mi copia permite traducirlo con Zend_Translate y los comentarios están corregidos. También corregí unos warnings menores. Además le cambié el prefijo a las clases de “Core_” (originalmente en zf-datagrid) a “Rox_”, para darle concordancia a mi estructura de directorios. Podría decir entonces que es un pequeño fork :B

También agregué todo jQuery UI al directorio público. Una ejemplo de esto es la pequeña demostración con el efecto acordeón que le agregué al widget de Login.

Y por último, agregué un directorio con XML’s en formato docbook, para poder usarlos en conjunto con la documentación creada con phpDocumentor.

Espero tener una documentación un poco más completa más adelante.

A veces no es bueno quedarse pegado con un objetivo, pudiendo romper otro más rápidamente.

Entre ayer y hoy, logré romper el segundo objetivo del Roadmap inicial de Gonium, consistente en crear la arquitectura modular para el Backend administrativo.

Ahora, la aplicación cuenta con 2 sistemas modulares independientes, uno para el Frontend (el sitio visible para todo usuario) y otro para el Backend (donde solo usuarios con privilegios pueden modificar cosas).

Esto significa, por ejemplo, que el módulo “user” que puede ver un usuario corriente (donde podrá modificar su perfil y esas cosas), será distinto del módulo “user” del administrador (donde se podrá crear/borrar/modificar cuantas usuarios).

Para dejarlo plenamente funcional, aún falta crear los módulos administrativos (así como los de usuario corriente), pero al menos, la arquitectura de directorios y bootstraping ya están adaptados para trabajar de esta manera.

Leer el resto de esta entrada »