Sobre compatibilidades entre versiones de PHP y zenphp

Hace un tiempo que cambié la versión de mi host dedicado de PHP4.2 a 5.2.6 y zenphp no ha tenido ningún problema para funcionar. Sólo un pequeño detalle a tener en cuenta con el fichero .htaccess…

Cuando escribimos redirecciones como por ejemplo:

AddDefaultCharset UTF-8
Options +FollowSymLinks
RewriteEngine on
RewriteRule ^noticias index.php/noticias
RewriteRule ^noticia\/(.*) index.php/noticias/leer/$1

en la que queremos que las www.midominio.com/noticias se redirija a www.midominio.com/index.php/noticias/ para encontrar el controlador por defecto, en PHP5 ahora se usa en lugar de <$_SERVER[‘REQUEST_URI’]> el parámetro <$_SERVER[‘PHP_SELF’]> dentro de

zenphp/clases/clase_zen_enrutador.php

de forma que estas redirecciones más complejas sean bien encauzadas sin tener que reescribir el módulo del enrutador que proporciona el framework…recordar que se puede escribir un enrutador y asociarlo a cualquiera de la s aplicaciones que estemos usando en el sistema y lanzarlo por medio de una función tipo “delegar()”.

Seguimos informando!

Pruebas con PHPUnit

Para instalar PHPUnit se necesita PEAR, para ello basta con hacer, en GNU/Linux :

apt-get install php-pear

Además necesitamos graph-viz para mostrar los resultados gráficamente:

apt-get install graph-viz

sudo pear install Image_Graphvi

entonces podemos hacer las pruebas con una macro que he reutilizado del proyecto ContactR.

~/csl2-zenphp/trunk/documentacion/test$ make

Para saber más, estoy preparando un PDF para completar la información.

Aumentando la eficiencia del framework

Después de muchos estudios y procesos de optimización,la última medición con el profiler PHP sobre zenphp, con el tema por defecto ha conseguido reducir al mínimo las llamadas al sistema, apertura de ficheros y operaciones ineficientes, incluso usando el compactador HTML [ver clase] lo que más se lleva es la función require de zen___carga_clase() que es la función usada para, como su nombre indica, cargar clases en nuestras aplicaciones, de hecho, usando dos aplicaciones y vinculando las bases de datos entre ellas, el resultado es el siguiente:

En zenphp no existe la función “autoload()“, que es una función muy famosa en PHP5: sirve para hacer un “require” de cualquier clase cuando la instanciamos por primera vez y no está en el ámbito actual.

Esto se hace para mantener nuestras aplicaciones sin sobrecarga, así que sólo usamos lo que cada parte de nuestra aplicación necesita en cada momento.

Veamos la gráfica:

  • Nos quiere decir, que mientras más clases usemos,más veces vamos a llamar a la función zen___carga_clase y con ello será más ineficiente, sin embargo no se hacen demasiadas llamadas ya que no solemos utilizar miles de clases en una aplicación pero si hasta cientos de ellas…
  • preg_replace() se usa muy poco, una única vez en la salida de la plantilla y cuando la compactación está activada, asi que si vamos a utilizar mucho procesamiento HTML y mostrar muchas veces la salida de la clase zen_plantilla, entonces es mejor desactivarla…cosa no muy probable…
  • Salta varias veces con la alerta E_STRICT.Hay algunas consideraciones a tener en cuenta con el tipo de error STRICT en PHP, ya que zenphp está escrito en PHP4 y PHP5…tiene características que serán eliminadas a partir de PHP6.x en adelante; …por lo tanto PHP5 intenta mostrar alertas cuando se hacen cosas como crear una variable con una referencia a partir de una función como puede ser un  constructor de una clase…son pequeños detalles pero consumen unos milisegundos de tiempo.
  • La función setlocale(); se toma alrededor de un milisegundo y medio, es la última ineficiente del conjunto inevitable…como sólo es llamada una vez no la considero para mejora, ya que es más ineficiente leer todas las constantes de idiomas (en lugar de usar fichero .mo [poedit]) como se hacía en los primeros prototipos del framework…
  • El resto de peticiones no se pueden considerar ineficientes…

Seguiremos optimizando 🙂

Nuevos Videotutoriales : MVC modificado y un proyecto de ensayo


Nuevos videotutoriales han sido añadidos a la sección de documentos de la Forja.

En este caso para explicar como funciona el modelo+visualizador junto con la sencillez de añadir un andamio o Scaffolding.

Se añaden junton con un vídeo del generador de aplicaciones Gtk y el inicio de un ensayo científico sobre la meditación.

Resultados de la encuesta sobre el generador de código fuente

Bueno, aquí están los resultados de la encuesta sobre el generador de código fuente.

La gráfica que sale es algo parecido a esto:

Aclaro las leyendas:

  • Verde claro: Aplicación con administración
  • Morado: Sólo esqueleto de aplicación
  • Naranja claro: Configurar campos en los modelos con XML
  • Rojo: Interfaz para configurar
  • Azul oscuro (arriba): Usarlo sólo para empezar como base entre PHP y el SDK
  • Verde olivo: Usar clases propias con ayuda
  • Naranja oscuro: Usarlo como CMS (Gestor de contenidos)
  • Azul claro (abajo): Generador con interfaz web

Está claro que el generador necesita que se ponga todo su empeño en generar clases simples que le sirvan al programador para empezar con el framework, añadiendo comentarios y documentación con enlaces a los manuales y ejemplos para que “pique” su propio código con total libertad.

Hay un nuevo vídeo del generador, estoy formateándolo para que no ocupe tanto….

Razones para usar las clases de zenphp:eficiencia y seguridad

1. ¿Construir el HTML mientras se hacen las consultas?…o más bien…
2. ¿Construir un array y después procesar el HTML?

Estudiando los casos: en (1) tenemos una consulta a la base de datos, esto requiere una negociación de conexión y el intercambio de información con el servidor mySQL por cada iteración, y rellenar con las tuplas obtenidas el HTML resultante, para ir mostrándolo o bien ir almacenándolo en una cadena.
Sin embargo en (2) tenemos un bucle que almacena los datos en un array y los devuelve para reemplazar sólo las etiquetas de un fichero HTML en una cadena, sin concatenar nada…

Es evidente que (2) es más eficiente que (1) en memoria y tiempo ,O( n ) con n=número de tuplas, porque construye el HTML y lo mantiene en memoria entre llamadas, en lugar de tener que recorrer todos los datos concatenando una cadena de texto enorme que es el HTML final y tomando su contenido de varias partes haciendo que la salida tarde más en ser devuelta (ya que necesita salir de la última llamada de la pila) , O( n* log(n) ).

Al margen de la eficiencia, una razón para usar zenphp es que es altamente funcional y se pueden hacer aplicaciones realmente rápido y en cuanto a seguridad, no se detectaron problemas, quizás llevo ventaja por no ser muy conocido.

Aquí una gráfica de las 20 aplicaciones PHP más inseguras:

Comunicando tecnologías : PHP + mySQL + AJAX + PERL + DHTML

Hoy se suponía que iba a estar recogiendo la aceituna pero ayer salimos para desquitarnos un poco a una fiesta de americanas xD asi que imposible varear nada ,entonces he picado un poco de artículo matinal 🙂 por cierto habis visto el Wii Aceitunero?

Cambiando de tema,…esto es un ¡Todo en uno!

Mi reto ha sido hoy sincronizar las tecnologías PHP + mySQL + AJAX + PERL + DHTML en un sólo script.

La idea es:

  • Una ventana con 2iframes, en uno se añaden los ficheros , se envían comprobando el estado con un script PERL/CGI su estado que es actualizado en la ventana en su iframe por medio de AJAX y al llegar a completarse dicha transferencia se envia una señal al segundo iframe que inserta una entrada en la BD con el nuevo fichero.
  • Todo ésto con comprobaciones de sesiones en PHP gracias a zenphp…y Funciona! pero bendito internet explorer, con navegadores como este podemos decir que el trabajo de programador web no está bien pagado ni mucho menos…porque me hace reescribir las aplicaciones 2 veces, …para el ie no es lo mismo :
    parent.document.getElementById(‘frm_Ficheros’).contentDocument.getElementById(‘frmSubeFicheros’);
    que:
    window.fileUpload.window.parent.frm_Ficheros.document
    lo mejor es que tengo el ie4linux y SI me dice donde está el error, y en windows no…es irónico ¿no?

Bueno,como viene siendo habitual, una captura:

Continue reading

Decisiones importantes

Dicen que nuestras decisiones marcan nuestro destino, por eso debemos ser nosotros mismos quienes decidamos en nuestra vida…

Veamos, las decisiones importantes del proyecto actualmente…

  • Usar gettext para los idiomas en la parte del núcleo de zenphp y el editor Poedit para crear los ficheros de idiomas (.po). ¡Es más eficiente que el uso de cadenas y constantes!…
  • Usar PHP/GTK para el generador de aplicaciones en lugar de generar por línea de comandos (cambio de chip)
  • Basar el generador de aplicaciones en modelos XML, así se puede actualizar el generador muy fácilmente, pudiéndose construir incluso un generador de generadores.
  • Diseñar “cartuchos” de aplicaciones como “Portal.XML” que generan con las opciones pasadas una aplicación completa de un portal web

La última decisión la he tomado porque ayer encontré que existen ya mecanismos que pasan de un modelo XMI construido en un editor UML a un conjunto de ficheros de clases de PHP, por lo tanto sería absurdo volver a repetir lo que otros han construido,asi que por lo tanto ,me centro en construir una aplicación PHP/GTK que utilice mi compilador y generador de aplicaciones basado en el paradigma de la programación orientada a aspectos, que lo tengo un poco olvidado 🙂

Con ello se cumple el objetivo del proyecto de ser un framework de aplicaciones web y ahora estoy con la parte de generador de aplicaciones en PHP/GTK.
Ahí va una captura del editor Poedit en primer plano y Kate al fondo (gracias al uso de un manualillo) 🙂

Buena práctica!

Comprobando la regla 90/10 en PHP

¿90/10?

Este post es para iniciar el estudio de comprobación de si, realmente se cumple el que una aplicación escrita en PHP siga la regla 90/10 del software, la cual nos dice que un programa pasa el 90% de su tiempo de ejecución en tan sólo un 10% de su código.

Tomando los resultados de un “profiler” PHP y analizadolos podemos ver dónde “vive” el código de nuestra aplicación y de este modo realizar las optimizaciones necesarias…Basándonos en el pasado reciente de un script, podemos predecir con una predicción razonable qué instrucciones y datos utilizará en un futuro próximo, para ello podemos usar la caché de la clase zen_cache ,el sistema de memoria de System V con las llamadas de PHP, guardar datos de consultas en una sesión, etc.

Recordemos que existen dos tipos de localidad
LOCALIDAD ESPACIAL
d(t) + k = d(t+n) con n y k pequeños
“Si se referencia un elemento, los elementos cercanos a él tenderán a ser referenciados pronto”.
Es decir, si estamos accediendo a un array, seguramente volvamos a acceder pronto a él, no tiene sentido hacer un array muy grande, deberíamos optimizar el código para no usar arrays más grandes que uno bidimensional…

“Las direcciones de memoria que se están utilizando suelen ser contiguas”.
Por eso, es mejor utilizar
JUSTIFICACIÓN: Los datos relacionados se almacenan juntos.
Las instrucciones se ejecutan secuencialmente. k = n = 1
LOCALIDAD TEMPORAL
d(t) = d(τ+n) con n pequeño
“Si se referencia un elemento, tenderá a ser referenciados pronto”.
“La información que se usará en un futuro próximo es aproximadamente la misma que se está usando actualmente”.

Para diseñar un sistema óptimo se realizan todas las posibles configuraciones en ficheros .XML que definan el comportamiento para cada parte independientemente, por ejemplo, si quiero disponer de un modelo de datos de noticias con una caché que se actualice sólo, creando un fichero .XML y a la hora de usar el zen_generador, para obtener nuestra aplicación de noticias, añadiré una propiedad para que se inserte una clase zen_cache y su configuración es:

  • que se actualice siempre que se añada/modifique/borre una noticia (o se fuerce a ello)
  • que genere los listados de noticias automáticamente y los guarde en un fichero .HTML que es mucho más rápido que generar todos los listados cada vez que se cargue el script de noticias…
  • que disponga de un administrador con soporte AJAX y un cliente básico
  • que use el tema por defecto de zenphp para mostrar la información de los modelos…

Bueno,resumidamente, es lo que estoy haciendo en estos momentos…

Framework español de PHP

Después de un interesantísimo debate que algunos de los lectores de esta entrada del blog han participado, damos las razones de por qué programar en un idioma u otro con nuestro código, siendo lo más común escribir en inglés, he decidido publicarlo por aquí ,en la lista de correo de la Forja del proyecto zenphp.

Quizás sea por éstos motivos por los que a la hora de buscar framework español en google sólo encontremos a kumbia.org…

Realmente no podemos hablar de conclusiones definitivas ya que estaríamos obligando a la gente a hacer lo que unos pocos pensamos, pero sí que podemos aconsejar.