PHP Senior

Excepciones: Cómo forzar un "backtrace" en un sistema que no usa try/catch

2009-10-26T09:00:00.004-02:00

Para los que venimos de haber trabajado, aunque sea académicamente, en otros lenguajes/plataformas como Java o .Net, trabajar con excepciones es un tema de todos los días. Al principio, cuando uno está aprendiendo y surge el primer volcado de una excepción (aparecen en pantalla muchas líneas con la información del error) hay una que resalta sobre todas y es la que demoramos más aprender a interpretar: el "backtrace" o ruta de ejecución desde que se inicia el sistema, todas las invocaciones que van sucediendo, en qué línea salta la ejecución, hasta terminar en el lugar exacto donde falló el sistema.

Recuerdo cuando probé por primera vez PHP5 (una beta) y lo primero que fui a probar fue hacer un try / catch forzando el fallo de una conexión a la base de datos con funciones nativas del lenguaje. Mi sorpresa fue mayúscula al comprender que los try / catch no funcionan a menos que nos aseguremos que la función que estamos usando retorne una excepción, y para colmo, PHP no lo hace por defecto! ;-) Así que no quedó otra que dejar las excepciones para nuestros desarrollos donde todo método de nuestras clases debía tener un throw new Exception('mensaje de error');

A pesar de mi desilusión, esto no era problema para los sistemas que hacíamos de cero de ahora en más, pero... ¿cómo haríamos con los sistemas que ya están funcionando y que no puedes salir a modificar miles de líneas de código para que un try / catch funcione?

Particularmente considero que una de las informaciones más importantes para poder hacer un debug de qué falló es el "backtrace". No es lo mismo ver en el log del sistema donde falló algo que ver quién invocó antes y con qué información para que fallara esa rutina.

Bien, hace un tiempo que lo buscaba y lo encontré por accidente en un foro, así que les comento la forma de uso y cómo lo pueden aplicar a sus sistemas "legacy":


class Debug
{
    public static function getBacktrace()
    {
        $ex     = new Exception();
        return $ex->getTrace();
    }
    public static function getBacktrace2String()
    {
        $ex    = new Exception();
        $trace = $ex->getTrace();

        /* Elimino la primer linea que 
           siempre es la misma y 
           hace referencia a la 
           invocación de esta clase */
        
        array_shift($trace); 

        $trace_ret = '';
        $linea = 0 ;
        foreach ($trace as $item){

            $linea++;

            $trace_ret .= 
                "(".$linea.")"
                ."[file: ".$item['file']
                .":".$item['line']."]"
                ."[".$item['class']
                .$item['type']
                .$item['function']."]"
                ."[args: " 
                .implode(',',$item['args']) 
                ."] ";
        }
        return $trace_ret;
    }
}

Luego, a continuación, tenemos una clase Log que lo único que hace es persistir cualquier información del sistema que queramos en un archivo de log, por lo tanto ahora agregamos la ejecución del backtrace y lo registramos en el log tal cual nos llega:


/* Método modificado de la clase Log */

public static function setError()
{
   $backtrace      = Debug::getBacktrace2String();
   self::logToFile('errores.log',$backtrace);
}

Listo, ahora automáticamente tenemos que cada vez que el sistema deba registrar un error, este, tendrá toda la información de backtrace, que se vería en nuestro sistema de la siguiente manera:

2009-10-26 09:40:11 (1)[file: /var/www/class/App.php:81][Log::errores][args: /var/www/class/Prueba.php,75,ERROR GRAVE: no se obtuvo el resultado esperado en el metodo: getProveedor,,0,SELECT * FROM proveedores WHERE estado = 1 AND id = 111 AND idCuenta = 1234] (2)[file: /var/www/public/sys/send.php:48][Prueba->getProveedor][args: 111,1234]

Lo cual si indentamos en base a los (n) que son los saltos que va dando la ejecución,

2009-10-26 09:40:11

(1)[file: /var/www/class/App.php:81][Log::errores][args: /var/www/class/Prueba.php,75,ERROR GRAVE: no se obtuvo el resultado esperado en el metodo: getProveedor,,0,SELECT * FROM proveedores WHERE estado = 1 AND id = "111" AND idCuenta = 1234]

(2)[file: /var/www/public/sys/send.php:48][Prueba->getProveedor][args: 111,1234]

Aquí se pueden ver dos saltos, el (1) es lo que veríamos siempre en nuestro log, la aplicación que propiamente falla, pero en el (2) estamos viendo desde donde realmente se inicio la ejecución que luego terminó fallando.

De todas formas, esto es un "parche", deberíamos usar try/catch en todos nuestros sistemas de ahora en más (si es que ya no lo estás usando), pero una forma de mejorar lo que ya existe es agregar un forzado "backtrace".

Espero que lo prueben en sus sistemas y les sea de utilidad ;-)

Propuesta de trabajo: Desarrollador PHP / PHP5 / POO / MySQL (Argentina)

2009-10-22T19:59:00.004-02:00

Les comparto la siguiente solicitud que me hace llegar una empresa, si les interesa pueden enviarme sus cv's a mi cuenta de correo (si no la sabes, no calificas para el puesto ;-))

Copio el aviso:

"Incorporaremos a nuestro equipo de desarrollo 2 personas con el siguiente perfil:

Requisitos:

- Experiencia comprobable en PHP
- Programación PHP 5 orientada a objetos (POO avanzado)
- Base de datos MySQL 5

Deseables (no excluyente):

- Frameworks PHP (preferencia Zend)
- Frameworks JavaScript (preferencia JQuery)
- Manejo de entornos Linux
- AJAX (XML y JSON)
- Maquetado en XHTML/CSS, HTML, WML
- Estudiante avanzado o graduado de carreras de informática o similar
- Capacidad de trabajo en equipo.
- Compromiso con calidad de productos y manejo de tiempos.

Empresa del rubro mobile (SMS/MMS/WAP),

Zona Palermo / Belgrano"

Tienen mi absoluta reserva.

Cursos SURFORCE: viento en popa!

2009-10-22T19:40:00.004-02:00

Sí, nuevamente estoy poco en el blog, con mis colegas (Andrés Guzman y Nicolás Fornaro) estamos en pleno trabajo por el dictado de los cursos ;-)

Como es de público conocimiento, la última fecha para inscribirse durante este año fue a principios de octubre ( ya que los cursos duran 2 meses) y estaríamos terminando las primeras semanas de diciembre.

En este momento están activos los siguientes grupos:

Introducción a Zend Framework (3 grupos, dos abiertos y uno privado)

POO para PHP5 (3 grupos, dos abiertos y uno privado intensivo)

Análisis y Diseño Orientado a Objetos (2 grupos)

Introducción a los Patrones de Diseño (1 grupo)

Taller Zend de Zend Framework (1 grupo)

De todas formas, les sugiero que se registren como usuarios, así cuando existan novedades les hago un envío de las próximas fechas de cursos (tentativamente finales de enero, principios de febrero, a confirmar).

En el caso de empresas, se pueden fijar otras fechas especiales, armar grupos privados, o hasta dictados intensivos (en vez de durar 2 meses, se puede hacer en 1 mes o hasta en 2 semanas, dependiendo el tiempo de dedicación diario del alumno).

Espero que para los próximos cursos no te quedes afuera! ;-)

[SURFORCE] Cambio de fecha de inicio de cursos: lunes 12 de Octubre

2009-10-06T02:37:00.000-02:00

Hasta esta hora estuve confirmando los pagos de los cursos y aún hay alumnos atrasados, por lo que para poder iniciar con los grupos completos vamos a tener que postergar unos días el inicio de los cursos.

Se extenderá el plazo hasta el próximo viernes para estar al día con el pago del curso y posteriormente SIN EXCEPCIONES no se recibirán más pagos y los cursos darán inicio el próximo lunes 12 de Octubre.

Aún quedan algunos lugares en los cursos para llegar al tope máximo de 20 alumnos, así que quién envíe el pago inmediatamente obtiene el lugar disponible que aún no se ha pago.

¡Si aún no pudiste confirmar tu lugar, esta es la última semana!

Cualquier duda o problema estamos a sus órdenes.

Saludos!

[SURFORCE] El inicio de cursos de Octubre se retrasa 1 día

2009-10-05T15:25:00.003-02:00

El fin de semana estuve confirmando pagos de los cursos y aún hay algunas vacantes y bastantes alumnos atrasados, por lo que para poder iniciar con los grupos completos vamos a tener que postergar provisoriamente un día el inicio de los cursos (martes 6/10).

Al finalizar el lunes (hoy) se evaluarán los cursos que inician mañana y cuales se postergan una semana hasta el próximo lunes para poder cerrar con el cupo previsto de alumnos.

¡Si aún no pudiste confirmar tu lugar, hoy es el día!

Ni bien tenga novedades les estoy enviando un email a todos los usuarios registrados

Sepan disculpar estos inconvenientes.

Discusión: "¿cuál es tu grado de madurez en POO?"

2009-10-05T03:07:00.003-02:00

Todo surgió respondiendo una consulta en un foro y me pareció interesante discutirlo aquí. Les comparto los "niveles" o "etapas" que considero que todo desarrollador pasa cuando decide dejar atrás la programación estructurada.

Generalmente todos empiezan por el primero y luego pocos llegan hasta el último (la mayoría solo logra llegar al 2 y se estancan en el 3):

"Programación Estructurada": el inicio, desde donde parten, la "nada" ;-)
"Programación Estructurada con uso de Objetos": usan objetos "sueltos / aislados", no los saben relacionar entre ellos, se reusan a leer material con "conceptos", creen que es mejor aprender a través del "prueba y error".
"Programación Orientada a Objetos Sin Conceptos Claros": "creen que lo hacen bien" pero luego heredan clases mecánicamente pensando que es el mejor mecanismo para reusar código.
"Desarrollo 100% OO": personas que invirtieron sabiamente su tiempo para aprender primero los conceptos para luego poder aplicarlos de forma correcta

Puedes seguir desarrollando estructurado y apoyarte en algunos objetos, pero lo ideal es que te vayas adecuando a la forma de trabajo con objetos y estructures todo el sistema de esta forma (y eso empieza por "pensar en objetos", no en código).

Nuevamente, "crear clases y jugar con objetos" es algo que todos podemos hacer, pero desarrollar "orientado a objetos" es un tema más de tener los conceptos claros que de saber la sintaxis de cómo se codifica.

Recomiendo que antes de preguntar qué es o qué no es POO, revisar el apartado de Wikipedia sobre POO y paradigmas de programación y las diferencias entre ellos.

¿Tú, en qué nivel de madurez estás? ¿crees que hay otros niveles o etapas más? ;-)

Primeros pasos en Zend Framework: cómo "aprender a pescar"

2009-10-03T14:36:00.011-03:00

Una de las prácticas que trato constantemente de inculcar es que "aprendan a pescar" y a no "depender que los alimenten en la boca".

Durante un curso, y particularmente después que termine, deberían siempre seguir estos pasos respetando el orden:

Paso 1) "Siempre consulta primero el manual oficial"

Buscar en el manual oficial http://framework.zend.com/manual/en/

Intenta tratar de identificar el componente que provee la funcionalidad. Por ejemplo, si no sabes el significado de los parámetros del método render(). Este método es parte del componente Zend_Controller - zend.controller.action y concretamente aquí comenta los parámetros zend.controller.action.viewintegration.render

Paso 2) "Consulta la API online del Framework"

En caso de no encontrar una explicación o esta sea breve, consultar la API online que se genera a partir de los fuentes a través del uso de PHPdoc - http://framework.zend.com/apidoc/core/ (en el combo superior pueden seleccionar el componente que quieren visualizar, Zend_Controller, y luego buscar la clase Zend_Controller_Action).

Paso 3) "¡Usa el código, Luke!"

Como complemento hasta pueden consultar el mismo código fuente de la librería, que ahí se aprende también mucho de cómo funciona el framework y hasta buenas prácticas de desarrollo: revisa el código de /library/Zend/Controller/Action.php

Paso 4) "Usa Google"

Y recién, solo recién, navegar en Google buscando artículos (y con cuidado, hay que aprender a discernir qué es bueno y qué es malo, ya que hay mucha basura).

En Resumen

Todo esto lo sacan navegando el menú de documentación del sitio oficial framework.zend.com, y desaconsejo terminantemente empezar primero buscando en google y creyendo en el primer artículo que encuentran en el buscador (aunque sea de mi autoría ;-)), ya que hay demasiados charlatanes que hablan sin saber y conceptualmente pueden llevarnos a cometer errores o adoptar malas prácticas.

Que te sirva, aprende a pescar por tu cuenta y no esperes que te resuelvan tus propios problemas ;-)

[SURFORCE]: ¡Últimos cursos del año!

2009-09-25T19:19:00.004-03:00

¡Estimados lectores, se vienen los últimos cursos del año! Hace unas semanas que se están recibiendo los pagos de las inscripciones:

Fecha de inicio de los cursos: Lunes 5/Octubre

Fecha límite para hacer los pagos: Viernes 2/octubre

Y como novedad para todos los alumnos que ya hicieron el curso de Introducción a Zend Framework, estamos iniciando el primer Taller de Desarrollo en Zend Framework, donde aplicaremos todo lo visto en el curso (y más), trabajando de principio a fin un proyecto completo de desarrollo a distancia (incorporando versionado con svn, instalación en servidores, gestión ágil de proyectos, etc)

¡No pierdas tu lugar! ¡De lo contrario, hasta el año que viene! ;-)

Para poder realizar la inscripción empieza por registrarte como usuario en SURFORCE

PD: cualquier duda o asesoramiento puedes enviarnos un email a info en surforce.com

Cajón del recuerdo: reflotando viejos posts anteriores a PHPSenior

2009-09-23T22:30:00.005-03:00

Se dio la casualidad que para armar el post anterior tuve que salir a buscar en mi "base de recuerdos" (los posts de mis blogs) para poder responder algunos temas que alguna vez traté. Inquieto como siempre, me puse a buscar en mi blog personal (el primero de todos los blogs que creé) y que luego, buscando especializar, dieron lugar a este blog, PHPSenior (al principio tenía tres, PHP5, Smarty y Pear, que luego se fusionaron en este blog ;-)).

Algunos recuerdos de cuando hablaba de todo un poco, pero particularmente sobre desarrollo web, web 2.0, servidores, etc, y que no han perdido vigencia (y no me gustaría que se olvidaran, al día de hoy los busco cuando quiero volver a repetir algo que hice por hace mucho tiempo ;-)).

Un resumen de los post más interesantes que puedo rescatar:

2005

2006

2007

Y en el 2005 escribía lo que sería mi frase de cabecera profesional:

"¿Lo quiere rápido, barato, o bien hecho? Puede elegir dos de las tres cosas."

– El espectro del Titanic (Arthur C. Clarke, 1998)

Espero que algunos de estos recuerdos les sirva ahora. ;-)

Pregunta recibida: "¿Consejos para hacer las interfaces web?"

2009-09-23T14:33:00.004-03:00

Esta semana recibí un email de una ex-alumna que me solicitaba mi recomendación sobre qué hacer y cómo las "interfaces web" en sus desarrollos PHP. Les comparto mi respuesta que puede ser útil a más de uno con la misma duda:

"En sí lo que estoy usando y recomiendo para los desarrollos web es algún framework general, como es Zend Framework. Con eso ya resuelves todo el problema de estructurar un proyecto, cómo organizarlo, además de múltiples clases que resuelven muchos temas repetitivos (como la persistencia, armado de la interfaz, etc). En las vistas tienes "funciones" que provee Zend (llamadas View Helpers) que simplifican mucho el trabajo (no deja de ser html o html generado a través de funciones), luego, la otra parte se hace con un buen uso de css y javascripts, y siguiendo la filosofía "productiva", te recomiendo usar siempre un framework, como bien podría ser jQuery.

No sé cómo estás con estos temas, pero la base es saber bien HTML + CSS (sin tablas) y luego complementarlo con JS (usando un framework para aumentar la productividad)

Enlaces recomendados

"Por qué usar tablas es estúpido" (inglés)
"3 Capas de Presentación"
"¿Debería utilizar estándares Web?"
y nunca está de más leer las guías breves de divulgación de la W3C (en inglés hay más información)

Si no quieres entrar aún con Zend, puedes ver sistemas de plantillas (templates) como Smarty, que también te resuelven muchos temas rutinarios y repetivos (revisa en mi blog por Smarty y verás varios artículos de cuando lo usaba, antes de Zend). Pero nuevamente, aquí ataca solo HTML, si te manejas bien con lo básico y simple, html solo es presentar los datos y css es dar estética, y js comportamiento ("3 capas de presentación"), si mantienes esto simple, las interfaces se hacen bien y rápido, fáciles de implementar (de lo contrario tienes un problema adicional al desarrollo puro y duro del sistema)."

¿Ustedes qué opinan? ¿agregarían algo más? ;-)

Plagio, segundo intento: "Desarrollador Senior" versus "PHP Senior"

2009-09-16T02:10:00.009-03:00

Parece broma, pero por accidente leyendo el sitio de illasaron.com llego a la siguiente noticia y me encuentro con que la misma persona del plagio anterior vuelve a la carga con un blog "poco original" (creado poco después del incidente que tuvimos), vuelve a copiar contenidos de este blog y ahora "los trabaja un poco más", cambia más palabras y sigue sin hacer referencia a su fuente original.

En mi cabezal dice desde hace años:

PHP Senior
Como convertirse en un "Desarrollador PHP Senior" y no morir en el intento... escrito por Enrique Place de SURFORCE

Ahora el agrega:

Desarrollador Senior
Como convertirse en un "Desarrollador web Senior" y no frustrarse en el intento... escrito por Arley Triana

Leyendo muy por arriba veo que tiene otro artículo parecido a uno que escribí, pero ahora le cambia más palabras para que sea más difícil de distingir... aunque sigue siendo evidente:

Nueva versión plagiada

Copio la captura del plagio que realizó en el blog anterior, y no puedo salir de mi asombro que siga intentando cambiar algunas palabras para que sea más difícil darse cuenta (hasta usa mi propio uml que hice con Argo)... pero sigue siendo tan evidente:

Vieja Versión Plagiada

Antes decía su Plagio Version 1: "tener una clase BaseDeDatos" ahora dice "tener una clase Database", antes decía "devuelve un objeto llamado bd" ahora dice "devuelve un objeto llamado $conn", pero mantiene los subtítulos "¿Ventajas / usos?" y los cambia por "¿Ventajas y usos?", etcétera, etcétera (si tienes tiempo encuentra las diferencias entre sus propias versiones de plagios que son bastantes y muy cómicas).

¿Soy muy paranoico o estamos ante un sorprendente caso de estupidez humana?

Más información

Artículo original y el Plagio Versión 2, todo por el mismo "autor", Arley Triana

Cambio de fecha de inicio de cursos: 7/Septiembre

2009-09-01T09:07:00.002-03:00

Hasta esta hora estuve confirmando los pagos de los cursos y aún hay alumnos atrasados, por lo que para poder iniciar con los grupos completos vamos a tener que postergar una semana el inicio de los mismos.

Se extenderá el plazo hasta el próximo viernes (7/9) para estar al día con el pago del curso y posteriormente SIN EXCEPCIONES no se recibirán más pagos y los cursos darán inicio el próximo lunes 7 / Septiembre.

Aún quedan algunos lugares en los cursos para llegar al tope máximo de 20 alumnos, así que quién envíe el pago inmediatamente obtiene el lugar disponible que aún no se ha pago.

Para quienes sí hicieron el pago correspondiente, sepan disculpar el cambio de fecha. Desde ya les pido a todos que ingresen a http://usuarios.surforce.com y revisen que sus pagos y su asignación a su grupo se encuentra actualizada, de la misma forma, quienes compraron el libro de POO para PHP5, ya pueden bajarlo en conjunto con todo el material extra.

En caso contrario, por favor nos envían un email y lo revisamos.

Opciones del sistema:

Resumen de Compras, para ver todos los pagos acreditados
Cursos > Tus Grupos
Libros > Actualizaciones
Libros > Material Extra

Cualquier duda o problema estoy a sus órdenes.

¡Última semana, si no te inscribiste aún, luego no hay más excusas! ;-)

Copiar sin citar = Plagio

2009-08-26T13:47:00.019-03:00

Plagio #1

La verdad que estoy bastante molesto con este caso de Plagio. No es la primera vez que veo que una persona copia literalmente contenidos de este blog y los copia íntegros, y para peor, sin citar:

"Una persona comete plagio cuando copia o imita algo que no le pertenece haciéndose pasar por el autor de ello. Dicha acción, al estar protegida la obra legalmente por el derecho de autor, podría conllevar un juicio y una posible imposición de multas y la obligación de indemnizar los daños y perjuicios."

Post Original #1

Claramente los contenidos de este blog tienen licencia Creative Commons (ver pié del sitio) y se aplican algunas restricciones. Existen distintas versiones de la licencia que puedes optar según tus intereses: en este caso puedes copiar, redistribuir y hacer obras derivadas, siempre y cuando cites al autor y no sea con fines comerciales (no quiere decir que no puedas lucrar con los contenidos, pero para eso debes pedir permiso).

Plagio #2

Post Original #2

Lo correcto sería que hiciéramos un comentario de un artículo que nos pueda gustar, hacer alguna cita de algún párrafo, pero no copiar íntegro el contenido que no permite distinguir si lo escribimos nosotros u otra persona (a menos que lo aclares explícitamente, avises cuando inicia algo que no escribiste, le agregues comillas, etc), pero esto es lo peor y ya muestra muy mala intención.

Plagio #3

Post Original #3

Esta persona, el Ingeniero Arley Triana Morín, vive en Cuba y hace un año tuvimos una pequeña discusión: me envió un email haciendo una consulta técnica y como no le respondí "inmediatamente", directamente me insultó.

Plagio #4

Post Original #4

Ahora bien, estaba borrando suscripciones a blogs desde mi Google Reader y de casualidad tenía a esta persona registrada. Luego de revisar un rato y encontrar "familiares" algunos temas y artículos (a veces mi memoria me juega malas pasadas), me percato que son copia literal de contenidos de este blog que escribí hace algún tiempo.

Plagio #5

Post Original #5

Nota: para peor cambia los enlaces que hacen referencia a otros articulos de este mismo blog por las copias en su propio blog (muy prolijo), ni que decir eliminar algunos párrafos con comentarios personales o cambiar levemente algún título.

A las pruebas me remito.

En resumen: Arley, yo por lo menos te "cito", y soy el autor original.

¿Por qué usar un (zend) framework?

2009-08-13T08:57:00.003-03:00

Estas preguntas me la han hecho muchas veces, así que es buen momento para compartirlas en el blog :-)

¿Para qué sirve un framework?
¿Por qué Zend Framework?
¿Cuales son las ventajas de no hacer todo yo?
etc

La idea de los frameworks es que son "cajas de herramientas" que puedes aprovechar en tus desarrollos... la filosofía del desarrollo profesional debería ser "¿cómo harías para construir una casa con las manos y sin martillos? imposible, no terminaría nunca, debo usar herramientas..."

Por ejemplo, no tienes que crearte tu propia clase de persistencia para recuperar o guardar datos, lo cual incluye además de lo básico, muchas funcionalidades que te ahorran tiempo y hasta te dan mayor seguridad por controles internos que ya incorporan de fábrica.

Si le sumamos que el esquema de trabajo es MVC, ya te da una forma de organizar tus sistemas, donde colocar cada cosa, etc, que te permite estandarizar y ahorrar mucho tiempo.

Un ejemplo bastante común: tú quieres validar un email que recibes de un formulario, en vez de tener que implementar toda esa parte (y hacerlo bien) puedes hacer uso de clases existentes como Zend_Validate_EmailAddress()

     $email = $this->getRequest()->getPost(' email', 'none@example.com');
$validator = new Zend_Validate_EmailAddress();

if ($validator->isValid($email)) {
 // email seems valid
} else {
 // email seems invalid; Outputting the reasons
 }

Listo, sigues adelante y programas el resto de lo importante de tu sistema, ya que lo que te importa es terminar el trabajo, entregar el sistema y cobrar al cliente.

De alguna forma, muy resumida, te "profesionaliza".

No sé si quedó claro el ejemplo ;-)

PD: se podría decir que lo importante no es si usas Zend Framework (más allá que yo lo use), creo que deberías por lo menos conocer alguno y estudiarlo en profundidad para sacarle provecho en el reuso de componentes y experiencia de la empresa o grupo que lo desarrolló. Siempre existirán ventajas, más si tu eres un equipo reducido de desarrolladores y el framework fue hecho por un equipo más grande y especializado en su diseño y desarrollo, no lo hicieron en su tiempo libre.

"Apóyate en hombros de gigantes"

¿Entrando en la "optimización extrema"?

2009-07-26T22:00:00.003-03:00

Siempre fui renuente a todos los artículos sobre "optimización extrema", ya que en PHP es muy poco probable que sirva hilar tan fino como para decir que:

++$a es más rápido que $a++ (aunque encontraremos opiniones opuestas)

Que foreach es más lento que un for, o que para imprimir varios valores en un echo es "más rápido" hacerlo con "," que con ".", etcétera.

No será la primera vez que diré que me parece una locura este tipo de optimizaciones, no tienen sentido en un ambiente web, en un entorno LAMP, y particularmente para PHP... a menos que estemos usando este lenguaje para hacer grandes "cálculos científicos" en memoria, pero estimo que si necesitas esto, erraste el entorno y el lenguaje para hacerlo.

"Optimizaciones Reales"

Para el que no lo sepa, en la actualidad trabajo durante la semana en una empresa argentina relacionada con productos / servicios vinculados a los celulares, y nuestra principal tarea es -muy resumidamente- enviar y recibir SMS (aunque ahora estamos empezando a trabajar con MMS).

También desarrollamos sistemas de administración y estadísticas para nosotros y para nuestros clientes (que son sistemas que ahora se hacen mayormente con Zend Framework), pero para estos sistemas nuestro tráfico es "reducido y controlado", lo opuesto a un servicio público como podría ser una red social donde los usuarios van creciendo día a día.

En este caso, de los sistemas web comunes, la "optimización extrema" no tienen ningún tipo de efecto, más que intentar hacer las cosas bien dentro de los "parámetros conocidos" y muchas veces estamos hablando de hacer las consultas sql de forma correcta (algo que no es tampoco común para la media de los desarrolladores PHP).

Pero en el primer caso, nosotros somos una empresa que podemos "estar orgullosos" que hacemos el envío de SMS/MMS a través de un ambiente web que incluye Apache, MySQL y PHP (aunque muchos podría discutir que no es la mejor tecnología, tal vez sería mejor usar arquitecturas como Java y puedo llegar a estar de acuerdo con ellos).

Desde hace unas semanas estamos haciendo funcionar una aplicación masiva en la que existen miles de usuarios enviando miles de SMS para juntar puntos en modalidad de "trivia" (se envían preguntas y se deben responder con opciones como "A" o "B") para un concurso que durará unos meses. Cada MO (mensaje originado por el usuario) enviado equivale a una instancia de apache evaluando la información recibida, registrando todos los datos y respondiendo a continuación con un MT (mensaje originado por el sistema). El juego cambia de comportamiento de acuerdo al tipo de jugador, tiene incentivadores que motivan al jugador seguir en carrera, le informa los puntos, le envía nuevos desafíos, lo recaptura si deja de jugar por distintas unidades de tiempo, etc.

Y aquí es donde entra la optimización que yo le llamaría "extrema". Les comparto algunas prácticas que fui aprendiendo sobre la marcha para que las discutamos juntos a ver que les parece y si no son tan esotéricas como las "++$a versus $a++":

Evitar el acceso a la base de datos

Generalmente el "cuello de botella" de los servidores está en el acceso a disco, el consumo de procesador es mínimo, pero sí es crítico el acceso a la base de datos y el principal recurso es acceder al disco. Una decisión de diseño fue evitar en algunos casos acceder a una tabla para traer datos y los dejamos "estáticos" en un array dentro de una clase (evitamos conectar, consultar, traer datos, desconectar).

Desventajas: perdemos "flexibilidad" ya que en vez de tener un admin que acceda a una tabla hay que modificar el código en el fuente (en nuestro caso son datos que no cambiarán frecuentemente y más que flexibilidad buscamos rendimiento y que el sistema no quede sin recursos).

Evitar repetir el acceso a base de datos

Nuevamente, nuestro cuello de botella. Algo muy común cuando desarrollamos orientado a objetos es que cada objeto es independiente del otro, y si lo hacemos "3 capas", en algún momento cada objeto terminará accediendo a la base de datos por su cuenta.

Me ha pasado de implementar un log que activo con todas las consultas del sistema y ver que se repiten algunas consultas dentro del mismo acceso al sistema, una y otra vez, cuando en sí están trayendo la misma información.

Por ejemplo (el ejemplo no es real, pero lo que importa es el concepto), imaginen que tengo el nombre del usuario en la base de datos y cada vez que hago algo como $jugador->getNombre() hace un SELECT nombre FROM jugadores WHERE id = 100;. Como la instancia se usa en varias partes del sistema y requiere verificar información del nombre en distintas oportunidades, esta consulta se repite "n" veces. Para evitar esto se cambia la operativa por una "carga tardía" (lazy load), nunca cargar nada hasta que lo necesite (no cargues toda la información en el constructor del objeto), y cuando ya tenga el valor, y si es un valor que no tiende a cambiar/actualizarse, retornar su contenido sin ir nuevamente a la base (parece tonto, pero hasta que no lo detectas que lo estás haciendo no tomas conciencia de que debes evitarlo).

Antes lo podrías tener así:

Luego lo podrías cambiar por:

Mejorar el acceso a base de datos

Algo que es poco común que un desarrollador domine, hacer correctas consultas a las bases de datos, agregar índices según lo que necesitemos hacer, evitar los índices en los lugares que no conviene, verificar el tipo de cada campo y si realmente es el que necesitamos.

Algunas pautas que recuerdo ahora:

Revisa por qué campos haces normalmente las condiciones de tus WHERE y crea un índice (recuerda que las claves primarias generan implícitamente un índice).
Recuerda que por cada índice que agregues tu tabla se recarga si esta tienen que actualizar los datos constantemente, ya que hará un "insert" en la tabla real y luego deberá actualizar el índice (como si fueran dos tablas). Si tienes 100 índices, y es una tabla grande y con muchas actualizaciones, será mejor que te tomes el tiempo y veas cual puedes eliminar.
Diferencia las tablas de "lectura/escritura" sobre las de "solo lectura". Si tu tabla necesita hacer ambas y sabes que crecerá, limita la cantidad de índices (ver punto anterior), pero si es de solo lectura, puedes tomarte la libertad de agregar más índices que en el primer caso.
Usa los mismos tipos y largos en los campos de tus tablas: si creas jugador_id y es un int(11), que así sea en todas las demás tablas, ya que unir campos que son de distintos tamaños tendrá un costo de conversión al compararlos.
Diferencia lo que es un varchar de un char: si tus valores de texto serán fijos, es decir, tienes un campo de 100 caracteres que será probable que siempre esté lleno, usa char(100), si puede que esté lleno de caracteres o existan casos donde no tenga nada, o pocos (10 caracteres), define que es de tipo varchar (var = variable).
etc

En estos casos (bueno, siempre) el manual del motor de base de datos es tu amigo.

No tengas miedo de desnormalizar una base de datos

Lo aprendí con el tiempo, no ser extremista y purista, luego de aprender las reglas, descubre cuando se justifica romperlas para sacar más provecho ;-)

Nos pasó que ante un tráfico masivo de datos estábamos teniendo un crecimiento desmedido en tablas que registran la entrega y salida de SMS, y que cuando queríamos hacer un cruzamiento de datos entre otras tablas, las consultas nos generaban pérdidas de segundos muy valiosos.

Por ejemplo, si nosotros tenemos un sistema que maneja múltiples carriers, por lógica deberíamos tener en la tabla de participantes el número de celular y el número de carrier al cual corresponde. En sistemas donde las tablas de participantes pueden crecer exponencialmente no es conveniente que por cada MO tengamos que acceder a una tabla extra para saber esta información, por lo que en tablas importantes "desnormalizamos" su acceso y duplicamos estos campos para evitar tener que hacer un join contra una tabla extra (y así con otros datos).

Duplica campos en distintas tablas (número de teléfono, carrier, id de usuario, etc) para evitar tener que hacer joins contra una tabla que crece y se actualiza constantemente.

Evita acceder a los datos de producción para hacer consultas

Aunque puede ser obvio, evita tener un sistema de estadísticas para tu clientes que hagan consultas directas contra una base de datos en producción. Cualquier consulta compleja puede tirar el rendimiento de tu sistema. Puedes intentar duplicar la base en otro servidor una vez al día, o simplemente crear "tablas resúmenes" con un proceso que corre cada "x" horas y en vez de sumar todos los datos cada vez que se consulta, ya lo haces en la carga y el sistema de estadísticas muestra solo los totales.

Si quieres darte un lujo, solo accede a producción para dar datos "reales" con un "count", y si quieres acceder a tablas, que estas no sean las más usadas.

En resumen

Fuera que descarto que debemos diseñar bien nuestro sistema pensado cual será el contexto en el cual funcionará, pensar en las clases y sus relaciones, y ver si estamos programando correctamente, a menos que estemos hablando de muchas clases por cada vez que hay una invocación en nuestro sistema (estoy hablando de 50 clases o más), lo más probable es que la optimización no se deba hacer en el código PHP, probablemente esté más orientado hacia nuestra comunicación con la base de datos (y descarto que ya estamos usando algún sistema de caché del lado del servidor).

Sé que no es de todos los días tener este tipo de situaciones de cantidades masivas de tráfico, pero cuando ocurren, estos detalles afectan el rendimiento o directamente la estabilidad del servidor.

¿Tienes algún tips para compartir? ¿cual fue tu experiencia en estos casos? ;-)

Artículos relacionados:

Retomando los artículos del blog

2009-07-26T18:51:00.007-03:00

Estimados lectores, como sabrán (dadas mis actividades de público conocimiento y las otras, trabajo, familia, etc), he estado un poco alejado de este blog, aunque a veces escribo en mi blog personal, tengo bastantes reclamos de ustedes para que retome el ritmo aquí :-)

También voy haciendo micro-post a través de mis cuentas de twitter (la personal, la de este blog y la relacionada a SURFORCE y los cursos a distancia), pero obviamente no es lo mismo.

Intentaré seguir prácticas de otros blogs, hacer un resumen de temas aunque no me de el tiempo de desarrollar un artículo completo al respecto, pero por lo menos podré comentar temas del momento relacionadas con PHP y algunas experiencias más, y en caso de requerirlo a través de los comentarios, me extenderé en lo que pueda.

Así que, retomando ritmo, como quién dice: este lunes empiezo el gimnasio, sin falta ;-)

PD: siempre recibo sus sugerencias a través de email o en los comentarios de este blog, así que aprovechen este mismo post para tirar ideas de temas que les gustaría tratar en el corto plazo.

Abrazos! ;-)

Comentar código de forma "invisible"

2009-07-09T14:40:00.009-03:00

Este tema tiene un origen histórico, trataré de empezar desde el principio ;-)

Cuando hace años empezamos en el mundo estático del "html" (cuando el 95% de los sitios solo eran puro html sin dinamismo, sin un lenguaje de scripting), lo que aprendimos fue a "programar html" haciendo muchas tablas (no usábamos los div's como ahora) y para seguir la "cascada" de código le agregábamos comentarios usando el tradicional 

Por ejemplo:

Muy "cómodo" para hacer debug "manual" usando de apoyo los comentarios porque evidentemente era un "humano" el que debía controlar todo esto y se podía perder entre tanto código en cascada ;-)

Para los "técnicos" esto siempre fue desprolijo, ya que para nuestros futuros clientes o hasta curiosos, estábamos revelando detalles internos de nuestra aplicación / diseño. Está de más decir que no es para nada recomendable hacer comentarios técnicos importantes en ellos ya que es "código público" que cualquiera puede leer, y tampoco comentar código que no se va a usar, ya que es extremadamente desprolijo (si no lo quieres perder, respalda, o versiona).

Nota: no será la primera y última vez que veo en los comentarios de un código html insultos del propio desarrollador, que la verdad queda muy feo ;-)

Primer sugerencia, el código de producción debe estar "limpio", y si conoces algún sistema que pueda contener los comentarios en tu código de desarrollo e impida que quede en producción, úsalo.

Algunos ejemplos.

Usando el propio lenguaje de scripting: PHP

Cuando la tecnología evolucionó y empezamos a contar con lenguajes de scripting como PHP, la primera práctica que empezamos a adoptar fue el de embeber el código "dinámico" dentro de nuestro código html, pero dejamos todas las demás prácticas intactas, por lo que los comentarios seguían estando públicos en el html.

Con el tiempo, dejamos de "embeber" y ya no era tan evidente la manipulación del código html, empezamos a hacer invocaciones a funciones de tipo:

     generarCabezalHtml();
generarContenido('Hola Mundo');
generarPie();

Por lo que ya no es el "humano" que debe seguir tan literalmente el código, ver si cierra o no, porque podemos validarlo a través de herramientas, y luego tratar de seguirlo a través del código PHP (aquí también ayudan mucho los IDEs en la pre-validación del código y evitar errores).

Una opción posible es mover todos los comentarios html al código php y estos quedan "privados" dentro del sistema.

Si esto no fuera suficiente, aún se podría generar algo como una configuración que diga "habilitarComentariosHtml" y que genere html con comentarios embebidos, y una vez en producción, eliminar esta opción (pero estaríamos generando mucho código poco productivo para el sistema).

Sigamos un siguiente nivel en la escala evolutiva ;-)

Usando sistemas de plantillas: Smarty

Con los años esto no nos quedó muy cómodo y preferimos optar por un sistema de "plantillas" (templates), y limpiar nuestro código PHP. Smarty fue una de las mejores opciones por años, lo cual te ofrecía además un código simil PHP del lado del template, pero podíamos volver a caer en la misma práctica, hacer comentarios html públicos.

Repitiendo lo que hablamos en el punto anterior, podíamos adoptar el mecanismo de comentarios de Smarty, lo cual genera el mismo efecto que hacerlo desde PHP. Se hacía con {* comentarios *}

{* display dropdown lists *}
<select name="company">
{html_options options=$vals selected=$selected_id}
select>

La diferencia con el primer caso de "solo html" es que lo estamos haciendo en la plantilla y no es público, y tampoco lo estamos haciendo del lado de PHP ya que toda la parte de generado de html era responsabilidad de Smarty (como una separación de capas).

Siguiendo con la evolución...

Nos pasamos a Zend Framework y usamos "Vistas"

Las vistas son como al principio de nuestra era, código html donde se embebe código PHP de la siguiente forma (un mix entre PHP embebido y sistema de plantillas).

Y volvemos al principio, he visto muchos proyectos que para poder hacer seguimiento de lo que generan de html tienen comentarios públicos html por todos lados, por lo que mi sugerencia final es... hagamos los comentarios dentro de la la vista, dentro del código PHP embebido y no dejemos expuestos nuestros comentarios internos.

Existen también herramientas que limpian el código, lo compactan y hasta te lo ofuscan, bien podrían ser una alternativa.

Pero la idea es esa, trata de no dejar comentarios que los pueda leer todo el mundo, sé ordenado y limpio. En lo personal cuando voy a ver páginas de diseño web que se ufanan de seguir "estándares", descubrir luego tablas o comentarios del tipo "abre tabla", "cierra tabla", etc, no me dejan muy tranquilo.

¿Qué opinas? ¿cuales son tus prácticas? ¿o no te importa que puedan descubrir leyendo el código de tu sitio? ;-)

Cursos SURFORCE: ¡falta una semana para iniciar!

2009-06-28T12:53:00.003-03:00

Para todos los que están interesados en participar de los cursos de educación a distancia, les comento que queda solo una semana para empezar, la cual fijamos como primer lunes de julio (6/7).

El cupo máximo para un grupo son de 20 alumnos, posteriormente se abre un siguiente grupo que iniciaría una semana después (13/7).

El estado actual de los lugares confirmados:

Introducción a los Patrones de Diseño para PHP5 = 7
Análisis y Diseño Orientado a Objetos para PHP5 = 9
Introducción a Zend Framework = 10
POO PHP5 2009 + Libro = 19

Recordatorio, aún quedan registraciones sin confirmar el pago, pero, quién se registre ahora y pague inmediatamente obtiene el lugar disponible.

Se recibirán los pagos hasta el viernes inclusive, no se recibirán pagos durante el último fin de semana, ya que lo usaré para preparar los sistemas para iniciar los cursos.

Por lo tanto ¡última semana! ;-)

Google Docs para gestionar proyectos a distancia (actualización 23/6)

2009-06-19T20:29:00.012-03:00

A veces las herramientas simples pueden ser de gran utilidad cuando no contamos con infraestructura en sistemas, problemas de tiempo o por no haber encontrado la herramienta "ideal" (existen muchos sistemas, pero a veces hacen más de lo que necesitamos y se vuelven complejos de usar).

Lo bueno de usar Google Docs es que te resuelve muchos problemas de forma muy simple, agregando una característica muy importante: se puede acceder remotamente desde cualquier navegador sin siquiera necesitar un servidor dedicado y su curva de aprendizaje es muy suave... ¿quién no sabe usar una planilla electrónica?

Fundamentalmente hay que usar un poco de imaginación y bien podremos aplicarlo para gestionar un proyecto web a distancia... como lo estamos haciendo ahora en la última tarea del curso a distancia de Análisis y Diseño Orientado a Objetos, aplicando técnicas de gestión ágil entre 4 personas ;-)

Aquí se puede visualizar la organización de la planilla, compartida entre 4 personas, donde tienes dos grandes divisiones que representan zonas de trabajo: el "Frontend" (la parte pública del sistema) y el "Backend" (la parte privada, el "admin" del sistema). Posteriormente agregamos el título de la tarea y una breve descripción de lo que involucra (no más, esto ayuda a dimensionar claramente lo que lleva hacer el sistema sin ambigüedades y costos ocultos).

Forma de trabajo

Una vez definidas las tareas macro, podemos empezar a agregar las tareas "micro" o sub-tareas, para llegar a afinar lo que hay que hacer, por ejemplo: al principio definimos una tarea "login" que era solo "involucra mostrar el formulario", pero luego lo extendimos porque nos dimos cuenta que además había que hacer "agregar validación por clave".
La idea es que las prioridades se definen de acuerdo a su aparición en la planilla, es decir, lo que está arriba es más importante que lo que está abajo. También pueden ver esto en las divisiones más grandes como Frontend y Backend, en este caso, como estamos siguiendo una "metodología ágil", nuestra prioridad es hacer entregables "visibles para el cliente", así que empezamos por el Frontend.
Para auto-organizarnos, cada desarrollador toma la tarea que quiere hacer de la lista (siguiendo el orden de prioridad) y luego la marca con "verde" y pone su nombre en la columna a la extrema derecha. Así, todos sabemos quién está haciendo qué y así podemos tomar la siguiente tarea, evitando "cuellos de botella" ya que no existe alguien que deba asignar tareas al equipo, siempre hay algo para hacer y evitamos tiempos muertos.
Una vez terminada, se colorea en "gris".
Si queda suspendida por algo, usaremos un color "amarillo".
etc.

Otra cosa que usamos son las solapas al pié de la planilla para agregar otras secciones en el proyecto, como links a documentación (también documentos web compartidos), separar los bugs de las funcionalidades, etc.

Lo bueno es que en un momento dado podemos estar varias personas a la vez en la planilla (desde distintos países) y todos vemos en el instante lo que pasa y hasta podemos usar el chat a la derecha para discutir algún tema en particular.

Todo con una simple planilla web.

Si lo quieres ver, también puedes hacer el documento público para que tu cliente siga los avances del proyecto ;-)

¿Qué más se te ocurre que podrías agregar? ¿algún otro sistema simple que uses y quieras compartir? ;-)

Actualización

Luis Artola, estimado colega, levanta el guante y hace un post comentado su experiencia usando Google Docs en la gestión de proyectos.

SURFORCE_CURSOS: temarios disponibles!

2009-06-12T03:19:00.003-03:00

Se encuentran disponibles los temarios de cada curso que estarán iniciando a partir de los primeros días de julio. También, durante este fin de semana, quedará habilitada la posibilidad de pagar a través de la web vuestro lugar en los grupos de los cursos (Paypal, Western Union y giro bancario si estás en Argentina).

Antes que se inicie el proceso de pagos, le estaré comunicando a todos los usuarios registrados.

PD: sepan disculpar las demoras (tengo bastantes correos pendientes). Esta semana hemos estado con pequeños problemas de salud (comunes para el invierno) lo que obligó a estar algunos días en cama.

¡Saludos! ;-)

Lo bueno de usar un IDE + SVN (captura)

2009-06-08T20:14:00.007-03:00

A veces entramos fácilmente en la discusión de si usar un IDE o un "Editor con Esteroides", o si usar o no un SCM, etc, bueno, aquí un ejemplo de lo que es retomar un proyecto que dejaste colgado y no te acuerdas qué fue lo último que modificaste localmente con respecto a lo último que tienes en tu servidor de producción.

Usando Netbeans 6.7 RC2 + SVN, abro el fuente y le doy a la combinación "ALT + D" (lo configuré así para que me ejecute el comando diff de SVN), lo cual muestra gráficamente las diferencias entre ambas versiones.

Lo que está a la izquierda es lo último versionado, lo que está a la derecha son los cambios locales que hice hace unos días (agregando un control para que antes de asignar verifique si están registradas las variables).

Lo bueno es que si cometí errores, puedo presionar sobre las "x" rojas y eliminar las líneas locales diferentes que no quiero dejar (de todas formas puedo volver atrás cuando quiera y comparar las versiones que quiera, no importa cuales, y recuperar cualquier línea de código).

Para quién aún no usa IDE's y versionado, no, no es lo mismo que un "Editor con Esteroides" (si no te muestra el contenido público de un objeto, yo no lo considero un IDE).

¡Semana próxima: Segundo Semestre de Cursos a Distancia!

2009-06-05T14:46:00.005-03:00

A partir del lunes próximo iniciamos el armado de grupos y cobro de las reservas para los cursos del segundo semestre del año:

Programación Orientada a Objetos en PHP5 (3ra Edición)

Introducción a Zend Framework (2da Edición)

Introducción a los Patrones de Diseño (2da Edición)

Análisis y Diseño Orientado a Objetos (2da Edición)

Tentativamente la fecha de inicio es el primer lunes de Julio 2009, con los grupos que se hayan armando a partir de los usuarios que realizaron su pago. El cupo mínimo de alumnos será de 20 por grupo y se irá iniciando un grupo por semana, en caso de no llegar a los cupos mínimos, se posterga una semana.

El costo sigue siendo el mismo, un único pago de USD 50 por persona durante dos meses, y la forma de pago oficial es a través de Paypal y la alternativa a través de Western Union (solo si estás en Argentina podemos hacer una transferencia bancaria).

AVISO IMPORTANTE: para este nuevo período se abrirán menos grupos que en el primer período, principalmente por un tema de sobrecarga de trabajo que tuvimos en el primer semestre de este año, y que quiero evitar que nos atrasemos con algún grupo o que los docentes terminemos extremadamente cansados :-(

Si estás interesado, no pierdas un lugar a partir del próximo lunes, donde habilitaré el pago de los cursos y empezaré a armar los grupos que inician por semana.

Si aún no estás registrado en SURFORCE, ingresa TUS DATOS REALES (incluyendo la foto) en http://registracion.surforce.com (los datos son privados y confidenciales, sin ellos, no voy a enviar datos de pago ni habilitar alumnos bajo seudónimos ni nombres fantasía).

Los cursos se dictarán a través de Moodle (sistema de educación a distancia) en la dirección http://formacion.surforce.com

Saludos!

PD: también, a más tardar el lunes próximo, estaré entregando los diplomas a todos los alumnos que aprobaron los cursos del primer semestre.

Por actualizar apurado de ZF 1.7 a 1.8 (actualizado)

2009-05-02T13:50:00.006-03:00

Notice: Zend_Loader::Zend_Loader::autoload is deprecated as of 1.8.0 and will be removed with 2.0.0; use Zend_Loader_Autoloader instead in [..]/library/Zend/Loader.php on line 186

Interesante, ni bien lo solucione les comento ;-)

Actualización

Antes estábamos usando:

     include "Zend/Loader.php";
Zend_Loader::registerAutoload();

Ahora debemos usar:

require_once 'Zend/Loader/Autoloader.php';

$loader = Zend_Loader_Autoloader::getInstance();
$loader->setFallbackAutoloader(true);
$loader->suppressNotFoundWarnings(false);

Luego que lea un poco más me fundamentaré mejor sobre lo que hay que hacer de ahora en adelante ,-)

Nueva actualización:

3/5/2009 - Developing a Comprehensive Autoloader

Cómo usar componentes de Zend Framework fuera del MVC

2009-04-27T20:50:00.000-03:00

Uno de los caminos para crear una "plataforma de desarrollo" (y bajar costos de desarrollo) es tener unificadas todas las herramientas que usamos a la hora de desarrollar nuestros sistemas.

Por ejemplo, no deberíamos tener distintas clases de acceso a base de datos o generación de logs según el entorno que estemos trabajando (a menos que tengas una razón coherente para hacerlo ;-) ). Si desarrollas dentro de la misma empresa / proyecto tanto sistemas web tradicionales, sistemas de gestión, páginas wap, o aplicaciones de envío SMS (como es en mi caso), no debería haber razón para tener código duplicado.

Una "plataforma" debería servir para eso, tener ya resuelto los problemas triviales y habituales para concentrarnos solo en los problemas nuevos y no triviales.

Una de las grandes ventajas de Zend Framework es poder usar cada uno de sus componentes fuera de la estructura tradicional de MVC, evitando necesariamente tener que usar un controller, modelo y vista. Si ya usas Zend Framework, puedes aprovechar los componentes también de forma aislada, lo que reusas código y conocimiento en el desarrollo de sistemas (aprendes a usar un componente y lo sigues usando en todos los sistemas).

Un caso puntual es poder eliminar todas las clases "artesanales" que hoy día tenemos para la generación de logs y empezar a uzar Zend_Log.

"La forma de hacerlo"

La primera, es instalar en nuestros servidores en un lugar estandarizado las "librerías", como por ejemplo en /var/www/library instalar Zend Framework.

Luego, deberíamos crear un archivo de configuración para que nuestra aplicación pueda encontrar fácilmente los componentes de Zend. Mi sugerencia es que usen la función de "autoload" (Zend_Loader), así no tienen que estar viendo de llamar una a una las clases que necesitan cada uno de los componentes.

config.php

     
set_include_path(
    '.' . 
    PATH_SEPARATOR . '/var/www/library' .
    PATH_SEPARATOR . get_include_path()
);

include "Zend/Loader.php";
Zend_Loader::registerAutoload();

Y así incluiríamos ahora la clase Zend_Log en nuestros desarrollos:

test.php

     require_once 'config.php';

$writer = new Zend_Log_Writer_Stream('/tmp/test.log');

$logger = new Zend_Log();
$logger->addWriter($writer);

$logger->log('This is a log message!', Zend_Log::INFO);

Listo, ya tenemos un scripts en PHP común y corriente, pero usando ahora un componente del framework Zend.

Así deberíamos poder hacerlo con todos los componentes básicos (base de datos, logs, envío de emails, config, etc), y evitar tener que reinventar la rueda.

¿Te parece útil?

¿Una nueva razón para usar Zend? ¿otros frameworks te permiten hacer lo mismo?

"La decadencia de forosdelweb.com", parte II

2009-04-16T13:46:00.005-03:00

Si luego de leer varios comentarios "políticamente correctos" (aunque por dentro estén insultándote), este último comentario terminó de dejar claro cómo son verdaderamente las cosas (que error ni error):

Veo que la filosofía es "estás conmigo o contra mi", no hay puntos medios ni sincero reconocimiento de errores, pura y llana "cortina de humo".

Al final de cuentas:

¿Todo esto fue una forma indirecta de intentar sacarme del foro de POO de PHP?

... el tiempo dirá.