Archivo de la categoría: Desarrollo

Gonium: Rompiendo el RoadMap

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.

Seguir leyendo Gonium: Rompiendo el RoadMap

Mezcla de consejos para codear, versionar y documentar.

Hoy encontré la respuesta a una duda bastante específica. Cada vez que revisaba un archivo fuente de Zend Framework, PHPDocumentor o cualquier otro proyecto, veía un tag de versión (@version) en los comentarios, donde el valor era una cadena que señalaba la fecha, hora y revisión en la que se realizó el commit y el autor de este, siempre con el mismo formato. ¿Como se hacía esto automáticamente?

Haciendo una pequeña búsqueda, dí con el origen. En CVS, existía la característica de reemplazar una palabra clave del código fuente, con una propiedad del repositorio/copia-de-trabajo. SVN heredó la misma característica. Se le llama «propiedades».

Es extremadamente útil contar con la información del Id, revisión, fecha y autor del archivo fuente, debido a que hay muchas situaciones fortuitas en las que es crítico encontrar uno o varios archivos fuente afectados por algo.

Por ejemplo, si encuentro un bug, puedo reportar que archivo y versión está afectado.

Si un tercero realiza una implementación en algún archivo fuente, que requiere una función especial, puede documentar su código, incluyendo desde y hasta que versión es compatible su código con el de la rama principal.

Esta y otras cosas más, que he aprendido en el camino, son aquellas que me gustan tener a mano y compartir, así que ¡manos a la obra!

Seguir leyendo Mezcla de consejos para codear, versionar y documentar.

OK, cambié de opinión. Me quedo con jQuery

Por las siguientes razones:

  • Cumple con lo que promete: «Write less, do more» (Escribe menos, hace más)
  • Es más ligera que Mootools, Dojo y otras…
  • No obliga a ensuciar el HTML.
  • Licencia Dual, ambas libres:
    Dual licensed under the MIT (MIT-LICENSE.txt)
    and GPL (GPL-LICENSE.txt) licenses.
  • Respaldo: Acualmente la usan Google, Dell, Mozilla, y muchas otras. En su web se pueden ver en «Who’s usign jQuery?». Si tantos «peces gordos» confían en una cosa libre, es por algo…
  • Me enteré en la semana, que tanto Microsoft (Visual Studio) como Nokia estaban interesados en incluirla en sus Kits de programación, sin hacerle cambios extraños y respetando la licencia. Fuente.
    • Si Microsoft y Nokia, empresas ligadas profundamente a su pasado «propietario», confían tanto en un proyecto libre como para anunciar eso, es porque de verdad debe ser buena
    • No es que les tenga confianza, pero hay una ventaja: Aquellos desarrolladores acostumbrados a las herramientas de Microsoft o Nokia, podrían fácilmente entender, arreglar o cooperar con proyectos que ocupen jQuery.
  • Teniendo tanto respaldo, otros desarrolladores (yo) podemos vernos beneficiados del desarrollo de lo los «peces gordos», sean de usuarios de Microsoft, Nokia, independientes, …
  • Razón trivial: Encontré otro ejemplo de DatePicker (pinchar una fecha en un calendario y seleccionar ese dato en un formulario), más bonito, completo y útil que el que estaba usando con Mootools.
    • Examinando este plugin, y la biblioteca de Plugins de jQuery, me parece suficiente para considerarla poderosa.

Así que ahora procederé a añadir jQuery al repositorio de Gonium, y aplicaré los mismos objetivos que en el post pasado, es decir, organizar los archivos, clases, etc…

phpDocumentor: como doxygen pero para PHP

Documentar el código es más que dejarlo bonito. Es hacerlo entendible.

«Comentar el código es como limpiar el cuarto de baño; nadie quiere hacerlo, pero el resultado es siempre una experiencia más agradable para uno mismo y sus invitados»
— Ryan Campbell

Uno de los propósitos iniciales de este blog, era combatir mi inquietante amnesia. No se ustedes, pero me es muy frecuente, que después de muchos días, semanas o meses sin ver el código que estaba trabajando, termino olvidando que hacía o como funcionaba.

«Ley de Alzheimer de la programación: si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez»
— Via Dan Hurvitz

Hay solo una forma de combatirlo: documentando.

Será una lata, pero creo (seriamente) que los lenguajes de programación debieran mandar advertencias cuando no documentamos el código fuente.

Cuando estuve en inserto en el proyecto GDT, me topé de cerca con Doxygen, una excelente herramienta para documentar el código en función de etiquetas especiales insertas en los comentarios. Muchos años antes, me tocó conocer otra grandiosa herramienta, que ayer re-descubrí: phpdocumentor.

Seguir leyendo phpDocumentor: como doxygen pero para PHP

Roxydemo!

Ayer no se porque me dió ganas de probar mi código inútil proyecto personal en un hosting gratuito.

Mientras lo hacía, comenté aquello en mi canal de irc favorito. Fue entonces cuando @janitux me comenta que tenia un hosting y un dominio en desuso.

Igualmente planeaba contratar un dominio y hosting más adelante para levantar un demo. Pero gracias a esto puedo adelantarlo.

Para mirarlo (por ahora nada más que un simple home), pueden acceder acá:

Demostración

Y para mirar las fuentes, pueden acceder al repositorio acá:

No esperen mucho, pues muchas características básicas de uso aún no están implementadas. Lo importante es probar como funciona el backend en un «ambiente de producción» . Es muy distinto probar las aplicaciones así que en el «ámbiente de desarrollo», donde todas las condiciones necesarias son modificables por el desarrollador.

Por el momento, el único módulo o sub-aplicación interesante que puedo mostrar es http://gon.boaboa.org/twitter Espero que les guste. :B

Por el momento va bien. Gracias a ello logré encontrar algunos detalles que no había visto en mi ambiente de desarrollo.

Gracias @janitux, espero poder sacarle provecho 😀 .

ZendFramework: problemas de codificación de caractéres con la Base de datos.

Este es otro caso en que me pena el tema de las codificaciones de caracteres.

SIEMPRE que uno trabaje con Bases de datos, sobre todo en paises de habla no-inglesa, se esta expuesto al tremendo cacho (problema) de manipular datos con caracteres no-ascii, como por ejemplo las ñ-Ñ y diversas vocales acentuadas, tildes, apostrofes, cremillas, tongos y cuanta modificacion rara se le pueda hacer a una letra.

Hasta ahora, he trabajado TODO con codificación utf8 por ser más amplia en este sentido que las otras codificaciones corrientes (iso-8859-1*, latin1, …).

Motivo

Trabajando con Zend Form, note un extraño comportamiento. Cuando establecía manualmente un dato en un campo, si este venía acentuado, entonces al dibujar por la vista, aparecía en blanco.

Haciendo un var_dump( $dato ); descubrí que la cadena de texto venía con caracteres mal formados. Preguntando en Foros del Web y navegando, dí con una pista.

Seguir leyendo ZendFramework: problemas de codificación de caractéres con la Base de datos.

ZendFramework: Manejar errores de los Controller Plugins

Si han trabajado con Zend Framework usando el patrón MVC, sabrán lo que es el Front Controller y sus «Action Plugins».

A principios de este año me topé con un problema que dejé pasar, hasta ahora.

Al configurar el FrontController, uno de los parámetros usuales a fijar, es registrar y configurar el plugin ErrorHandler. Este plugin permite redirigir a un módulo->controlador->acción cuando se dispara una excepción durante el Dispatch Loop. Esto en conjunto con establecer que el FrontController no dispare excepciones, permite presentar un bonito error manualmente, con los detalles que el desarrollador quiera mostrar.

Sin embargo, hasta hoy, no fui capaz de entender porque cuando otro Plugin disparaba una excepción, esta pasaba de largo, sin hacer caso a mi ErrorHandler.

Afortunadamente, hoy me desperté con el pie izquierdo, por lo cual me di la maña de examinar el código del Framework (bendito sean los kits de desarrollo libres). Y afortunadamente conozco Xdebug, que me facilitó la tarea de encontrarlo.

Es un problema de diseño del ZendFramework, pero lamentablemente, según lo que pude leer, no se me ocurre uno mejor que proponer. En cambio, mi solución es OLVIDAR el plugin ErrorHandler que trae el framework, y hacer uno manualmente, con una maña más mañosa que el original.

Seguir leyendo ZendFramework: Manejar errores de los Controller Plugins

Desafío: controlar acceso a través de huellas

Hace pocos días, me contacto un amigo con el que trabajé hace unos años. Aquel fue «mi primer trabajo», aun cuando fue más freelance que cualquier otra cosa.

Esta vez no fue un «sistema web», sino algo un poco especial. Teniendo 2 situaciones distintas, es necesario controlar el acceso de ciertas personas a ciertos lugares. En este caso, el problema en realidad es más cultural que informático, pero bueh…

La idea es implementar un lector de huellas digitales (tambien conocido como lector biométrico, fingerprint, etc…), que este logre identificar contra una base de datos con los socios (usuarios) y finalmente conceda o deniegue el acceso dependiendo de las condiciones en que se encuentra el socio (quien pondrá el dedo).

sadg
Lector de huellas casero

Es un desafío interesante por varias razones. Si pudiera elegir libremente, habría pensado en implementar PC’s terminales con Linux, ya que existe un api libre para programar estos aparatitos. Incluso, un compañero de la universidad logró habilitar el lector de huellas de su notebook con eso.

Pero estoy sujeto a algunas restricciones:

Seguir leyendo Desafío: controlar acceso a través de huellas

Traducción de Zend Validate con gettext y poedit

Zend Framework cuenta con una lógica de Formularios bastante «chori».

Consta de una clase Zend_Form, algunas cuantas Zend_Form_Element_* y algunos Zend_Form_Decorator_*.

Lo «chori» es como funciona. Integra en un solo objeto la lógica de los datos de un formulario, la vista html, el procesamiento de las entradas por cada campo (elemento) y la validación de los valores ingresados.

Así nos ahorramos la lata de escribir varios scripts por separado. Antes era necesario coordinar los nombres de los elementos con las claves que llegaban por $_GET o $_POST. Al hacer cualquier cambio al formulario html, podía provocarle hipo al script validador.

Ahora solo es necesario declarar el formulario, agregarle los validadores a cada elemento (que sea necesario), los decoradores del formulario y/o de los elementos y ya esta todo cocinado. Se pasa el objeto $form al script de vista y automáticamente es dibujado como HTML, y nuestro script Controller puede perfectamente procesar los mismos inputs declarados en el Form.

Tutoriales y documentación para trabajar con Zend Form abundan, así que no voy a profundizar en ello.

El Problema

Los validadores arrojan mensajes de error cuando el valor recibido no coincide con su criterio de validación. Pero estos mensajes estan en idioma inglés, definidos en constantes de clase en cada clase Zend_Validate_*.

La solución

Zend_Translate permite introducir texto traducible en nuestro código.

Escoger un adaptador de traducción

Entre sus adaptadores, mi favorito por el momento es el basado en Gettext. Las ventajas de gettext son múltiples:

  • Las traducciones están en un formato binario y no texto plano, lo que facilita evitar problemas como la codificación de caracteres en distintos sistemas operativos. De hecho, la codificación es un parámetro que se guarda en el mismo binario, ahorrando el «parseo» para detectarlo.
  • PHP es compatible con gettext, por lo tanto, la integración es directa. Cuanta con funciones nativas para cargar las traducciones y además soporta la macro _(‘texto’) para convertir cualquier string en su traducción.
  • El rendimiento de carga uso es altísimo comparado con cualquier otro adaptador basado en texto.

Por su puesto que, dada las circunstancias, se puede escoger cualquier otro adaptador. Solo que gettext es mi favorito 😀 .

Acá hay más detalles sobre Zend_Translate y sus adaptadores.

Zend_Form permite usar automáticamente los mensajes que ya estén traducidos cuando ocupamos validadores con él. ¿Pero como se hace la magia?

Seguir leyendo Traducción de Zend Validate con gettext y poedit