Javi Sanromán

Hoy, después de pelearme con el eclipse un rato (tampoco fue como para una separación seria, solo unos días hasta que se me pase) me he dado una vuelta por netbeans y me entero de que la nueva versión 6.1 ya trae el plugin integrado para soportar php. Es mas, nos podemos descargar una versión de este ide solo con el plugin para php por la módica cantidad de 16MB.

La he instalado y las primeras impresiones son buenas pero…

El editor está bien, el autocompletado de funciones funciona!, la refactorización se reduce a renombrado de ficheros y ni siquiera lo hace bien, excelente integración con svn (igual que la versión javera), en principio parece que la integración con xdebug es bastante buena pero solo lo he usado con proyectos demo.

Pero… el mismo pero de siempre, sigue siendo muy pesado, consume una grandísima cantidad de memoria. Será momento de plantearme un cambio de equipo? mmm, no se no se, creo que aguantaremos un poquillo mas.

http://wiki.netbeans.org/PHP

Ayer un compañero de trabajo me habló de propel el cual no conocía (gracias Juanjo :-)). Es un orm para php basado en torque competencia directa del conocido hibernate en el mundo j2ee.

Propel está disponible en los repositorios de pear por lo que su instalación puede llegar a ser de lo mas sencillo si utilizamos estos repositorios:

o igualmente sencilla al estilo tradicional, descargamos paquetes, descomprimimos paquetes :-).

Propel depende de otros paquetes pear que necesitamos tener instalados (phing, creole y opcionalmente Log):

También necesitaremos el modulo php5-xls si no lo tenemos ya, un simple apt-get install php5-xls bastará en ubuntu.

En el directorio propel/generator/projects tenemos un proyecto "bookstore" que utilizaremos para nuestra primera toma de contacto. Tenemos 3 ficheros:
- build.properties: Definimos las propiedades de nuestro proyecto necesarias para generar nuestros modelos a partir de las definiones xml.
- runtime-conf.xml: Definimos las propiedades de nuestro proyecto, nombre, conexión con BD, paquetes de clases a generar, etc, a utilizar en nuestro proyecto, este xml se trasformará una vez construido el modelo de clases en un array de datos definido en nuestro próximo fichero de configuración.
- shema.xml: La definición de nuestro modelo de datos a partir del que generar el modelo de clases y los scripts .sql necesarios para generar nuestra BD.

Una vez tenemos los ficheros anteriores correctamente configurados simplemente necesitaremos ejecutar:

Script que encontramos en propel/generator/bin y que nos genera dentro de nuestro proyecto un directorio build con:
- clases: Todas las clases que representan a nuestro modelo de datos y a través de las cuales nos comunicaremos con nuestra BD.
- conf: Nuestros ficheros de configuración, aquel generado a partir del anterior runtime-conf.xml.
- sql: Los scripts *.sql para contruir nuestra BD.

El que para generar una entidad necesite crear 5 ficheros me resulta engorroso, creo que muchas de las funcionalidades escritas en estas clases deberían estar incluidas en el núcleo propel:
- Entidad.php: Clase vacía que deberemos utilizar para extender la funcionalidad de esta entidad.
- EntidadPeer.php: Clase vacía que deberemos utilizar para extender las operaciones de consulta y actualización contra la tabla a la que representa esta entidad.
- om/BaseEntidad.php: Clase generada con todos los atributos getters&setters y demás operaciones de nuestro modelo definido en el xml.
- om/BaseEntidadPeer.php: Operaciones básicas de consulta y actualización contra la BD a la que representa esta entidad.
- map/EntidadMapBuilder.php

No creo que lo utilice por ahora, me gustaría que tuviera un nivel abstracción mayor sin tener que recurrir a la generación de código, y por otro lado el proyecto al que podría aplicarlo ahora mismo estimamos que deberá soportar una gran cantidad de tráfico y creo que nuestros DAOS serán mas eficientes, de todas formas lo seguiré de cerca.

Os dejo una presentación de Hans Lellelid (uno de los directores del proyecto):

En días como hoy es cuando se echa de menos un hombro donde desahogar las penas, un compañero al que preguntar, o simplemente al que decir "¿esta bien verdad?, ¿y pq no funciona entonces?, es que no lo entiendo, ¿enviamos un bug?...y mil cosas mas sin sentido cuando finalmente encuentras los porqués".

Volviendo al proyecto en el que ya estoy sumergido necesito además de una 4 de mysql una 4 de php, y claro en mi ubuntu estoy con la 5. Venga a buscar soluciones.

Para tener 2 versiones de php corriendo en la misma máquina, sin virtualizaciones ni nada que este cacharro no esta para esos trotes, necesitamos tener una instalada como módulo y otra como cgi. Como módulo tengo la 5.2.3 y necesito instalar una 4 como cgi.

Voy a recurrir a los repositorios de http://www.dotdeb.org/mirrors para hacerme con la 4.4.8. Edito mi sources.list y añado los repositorios de dotdeb.

Tras actualizar los repositorios hago un apt-get install php4-cgi y primera en la frente, dependencia libzzip-0.12 incumplida (paso mucho miedo, pero con suerte no es recursiva), es lo que tiene recurrir a estas versiones antiguas empaquetadas. Nos vamos a debian http://packages.debian.org/etch/i386/libzzip-0-12/download descargamos e instalamos el paquete.

Ahora si apt-get install php4-cgi y php4 instalado. Instalamos además otros paquetes que necesitaremos apt-get install php4-curl php4-domxml php4-gd php4-gmp php4-imap php4-ldap php4-mcal php4-mcrypt php4-mysql

Ahora que tenemos php4 instalado y nuestro ejecutable en /usr/lib/cgi-bin/php4, editamos nuestro virtual host de apache:

y tenemos que activar el modulo actions (a2enmod actions) o no podremos ejecutar la linea Action php-script /cgi-bin/php4 .
Y con esto ya tenemos este virtual host utilizando la 4. Ala mañana mas que hoy ya es tarde.

Este fin de semana el cake me hizo otra de las suyas. Aunque pensándolo bien siempre podemos disculparlo por trabajar en beta.

El caso es que yo necesitaba mi propio AppController para incluir una serie de acciones comunes a todas las peticiones, y que se ejecutarían en el beforeRender() (justo antes de renderizar la vista y después de ejecutar toda la lógica de los controladores).

Esto en cake 1.1 se hacía copiando el app_controller.php a la raíz de /app, sobreescribíamos los métodos necesarios y listo. Y claro antes de leer nada fue lo primero que hice en cake 1.2. Pero no tuve suerte. Resulta que no encontraba los métodos que estaba declarando. Cake no estaba cargando mi app_controller sino el por defecto en /cake/libs/controller.

De primeras acudí a google (no conozco otra forma mas rápida de encontrar solución a este tipo de problemas) y tras comprobar que era al único que le sucedía tal cosa me fuí directo a http://manual.cakephp.org/complete/3/the-manual y la sorpresa cuando me encuentro con estas líneas:

Both controllers, helpers and models have a parent class you can use to define application-wide changes. AppController (located at /app/app_controller.php), AppHelper (located at /app/app_helper.php) and AppModel (located at /app/app_model.php) are great places to put methods you want to share between all controllers, helpers or models.

Lo estaba haciendo bien!, tras navegar por el registro de bugs llegué a esta conversación en el grupo de google , que seria de mi sin la comunidad!, resulta que para extender el app_controller en cakephp 1.2 debes situarlo en /app/controllers/app_controller.php y no en /app/app_controllers.php.

No me quejo, es el riesgo que se corre por trabajar en betas, además, quitando estos dos detalles cake y yo nos llevamos bastante bien. Aunque eso si, prefiero no tener documentación a tener documentación mentirosa.

Pues si con este inicio de mayo y un año mas encima cambiamos de proyecto y necesariamente hemos de utilizar mysql4.

En mi ubuntu gutsy (todavía no me he atrevido a actualizar) tengo instalada mediante apt la versión 5, así que no me quedaba otra que buscar la forma de tener las 2 funcionando en mi portatil ya que la opción de servidor de desarrollo en casa a día de hoy es inviable. Yo he compilado los fuentes de mysql4 para conseguirlo aunque tenemos otras opciones. En este provechoso articulo tenemos información sobre esto.

Lo primero es descargar los fuentes.
Descomprimimos y preparamos la compilación para indicar el puerto, socket y directorio de instalación, todos diferentes a la versión 5 actual claro:

Compilamos "make" e instalamos "make install".

Copiamos el fichero de configuración a la nueva instalación:

Creamos las BD (test, mysql, information_schema) necesarias para mysql ejecutando ./bin/mysql_install_db.

Iniciamos ./bin/mysqld_safe --defaults-extra-file=my.cnf indicando el fichero de configuración a utilizar.

Y listo, probamos si ha iniciado correctamente realizando una conexión: ./bin/mysql -h 127.0.0.1 -P 3308 -u root, especial atención a la ip y no "localhost" para que la conexión se realice mediante TCP/IP.

Y a currar en 5 y 4.

Nunca es tarde si el post llega.... bueno era algo así ¿no?. El caso es que después de bastante tiempo he aprovechado este puentecillo en el que tampoco tendremos curso para quitar este post atrasado.

En esta 5ª semana llegó el fin de los ejb's con un último ejemplo de ejb de mensaje (jms) que no voy a reproducir pues es muy parecido al ejemplo del post anterior. Y a continuación comenzamos con los servicios web, esa tecnología tan inmadura (por lo que cuidadín con las elecciones, cambios continuos y en general un jaleo de nombres, apis, versiones...) como de moda últimamente. Eso si!!, sin antes perder 3 horillas en una creo que inútil charla de igualdad de género a la que la xunta nos obliga en todos los cursos que financia, en fin, creo que los burros a esta edad seguirán siendo burros, y tampoco me parece el marco ideal para dar estas lecciones, opinión muy personal por supuesto.

Los servicios web son un conjunto de tecnologías (independientes de lenguaje y plataforma) que nos permiten el intercambio de datos entre diferentes máquinas conectadas a través de una red. Lo típico es utilizarlos bajo http (pues junto con su estándar son las dos grandes ventajas aportadas) y eliminar así los efectos de los firewalls (seguro que alguna vez habéis topado con uno). De todas formas os dejo un par de enlaces donde explican mucho mejor que yo:

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
http://es.wikipedia.org/wiki/Servicio_Web

Un breve esquema (desde el w3c):

Vemos la aplicación cliente que se conecta con el servicio web, envía datos a través de mensajes SOAP según las reglas descritas en el "contrato" WDSL.

En java tenemos api's y herramientas que nos ayudan a crear y desplegar servicios web. JAX-WS (que forma parte del proyecto glassfish y agrupa entre otras a SOAP 1.2, WSDL 1.1, WSDL 2.0, JAXB 2.0) nos abstrae de las tareas básicas para crear un servicio web. Nos aporta 2 buenas utilidades wsgen y wsimport que nos permitirán generar de forma automática los artefactos necesarios para generar nuestro servicio y las clases proxy que representarán el servicio web en local para los clientes. Luego a través de anotaciones, como viene siendo habitual, indicaremos que clase representa nuestro servicio, que propiedades se corresponden con los tags de nuestros xml, etc:

Un par de sencillos pero útiles ejemplos:
http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2/
http://java.sun.com/developer/technicalArticles/J2SE/jax_ws_2_pt2/

Y para terminar necesitamos un servidor que soporte jax-ws, en realidad nos serviría el propio tomcat, pero yo sigo trabajando con jboss así que me tocó instalar el soporte jax-ws que nos provee el paquete jbossws:
1- Descargamos jbossws.
2- Descomprimimos y renombramos ant.properties.example por ant.properties.
2- Editamos ant.properties y modificamos la propiedad jboss422.home indicando el directorio de nuestro jboss.
3- Ejecutamos ant deploy-jboss42 (mi versión es la 4.2 sino la que toque).
4- Iniciamos jboss y comprobamos en la dirección http://localhost:8080/jbossws/ que se ha instalado el soporte jax-ws en nuestro jboss.

Con esto ya tendríamos jboss preparado para desplegar servicios web, ahora solo nos falta hacer unas pruebecillas, quizás en otro post...

Cuantas veces este ha sido motivo de debate. ¿Merece la pena utilizar un sistema de plantillas estilo smarty para php?. ¿Acaso no es php un lenguaje de script suficientemente limpio y potente como para poder valerse por si solo como motor de plantillas?. ¿Que diferencia encontráis entre estas 2 lineas?:

¿De verdad creéis que la primera es mas sencilla?.

Como ya habréis intuido yo nunca estuve de acuerdo en utilizar un lenguaje añadido de plantillas, básicamente porque no me aporta nada. Por supuesto que estoy de acuerdo en separar las capas de presentación y lógica pero esto lo podemos hacer tanto con php como no hacerlo con cualquier motor de plantillas. Todo depende de como lo utilicemos.

Pero yo prefiero esto:

y no esto:

Por cierto tanto cakephp como zend framework han adoptado la primera opción de forma nativa, lo que no quiere decir que no existan plugins para poder utilizar algún lenguaje propio de plantillas.