jueves, 15 de septiembre de 2011

Problemas con wsdl2phpgenerator

Al utilizar por primera vez wsdl2phpgenerator me he encontrado con que se producía el siguiente error:

Fatal error: Call to undefined function _() in generate.php on line 42

Pues bien, para resolverlo hay que instalar la extensión Gettext (+info) de php. El procedimiento es el habitual: en el php.ini hay que activar la línea extension=php_gettext.dll.

miércoles, 13 de abril de 2011

Espacios de nombres en PHP (PHP Namespaces)

Además del dominio de la programación orientada a objetos y del uso de los arrays asociativos, hay otro elemento que es importante dominar para entender el código de Symfony2. Se trata de los espacios de nombres.

Hay una fantástica explicación  del concepto de espacio de nombres en esta página

Y el manual "oficial" en español se encuentra en http://php.net/manual/es/language.namespaces.php.

Algunos pequeños detalles a destacar:
  • Para entender el uso de "use" hay que tener presente que, tal y como se indica en la documentación, los espacios de nombres de PHP soportan dos formas de usar alias o importar: apodar un NOMBRE DE CLASE, y apodar un NOMBRE DE ESPACIO DE NOMBRES. Observe que importar una función o una constante NO ESTÁ SOPORTADO. He destacado algunas partes del texto en mayúsculas pues he "tropezado" con esto a la hora de entender la lógica de utilización de "use".

miércoles, 6 de abril de 2011

Instalación de APC (Alternative PHP Cache)

APC acelera el funcionamiento de PHP y su uso está altamente recomendado por Symfony.

Hay un completo manual en español en esta página: http://php.net/manual/es/book.apc.php y, en esta otra:  http://docs.moodle.org/en/Installing_APC_in_Windows están detallados (en inglés) los pasos a seguir para llevar a cabo la instalación.

Yo, finalmente, me he limitado a descargar desde http://downloads.php.net/pierre/ el fichero php_apc-3.1-svn20101116-5.3-vc6-x86.zip. Una vez descomprimido, he instalado el fichero php_apc.dll en la carpeta de extensiones de PHP (en mi caso C:\PHP\ext) y he editado php.ini añadiendo extension=php_apc.dll en el apartado "Windows Extensions". El fichero php_apc.pdb también contenido en el ZIP lo he ignorado, ya que desconozco su función.

He rearrancado Apache y verificado que aparece el bloque APC en el consultando un pfpinfo().

Si se instala una versión no adecuada de APC, Windows da directamente un error al intentar arrancar Apache. Esto me ha pasado probando con otros ficheros de http://downloads.php.net/pierre/ que, obviamente, no eran los correctos. Por si sirve de ayuda, el instalador de PHP que utilicé en su momento fue php-5.3.4-Win32-VC6-x86.msi.

jueves, 31 de marzo de 2011

Un proyecto, múltiples dominios con Symfony

En el momento de escribir esta entrada sigo sin haberme "sumergido" realmente en Symfony2. He estado aprendiendo a manejar herramientas (xDebug, NetBeans, Twig, etc) para mejorar mi entorno de trabajo, y conocer recursos utilizados habitualmente en Symfony. Todo para intentar abordar el famoso framework con la mejor preparación posible.

De todas formas, antes de seguir adelante he querido echar un vistazo a la posibilidad de, con un único proyecto de Symfony, gestionar el contenido de varios dominios. De hecho es uno de mis objetivos más importantes. Por lo pronto he encontrado dos enlaces que, aunque no son de Symfony2 sino de su predecesor, quiero "guardar" en esta entrada para analizarlos con calma en cuanto pueda.

http://www.programania.net/diseno-de-software/un-proyecto-multiples-dominios-con-symfony-1-4-y-propel-1-5/

http://mirmodynamics.com/post/2008/12/22/Multiple-domains-for-one-symfony-project,-the-basics

Espero poder comentarlos en breve...

sábado, 19 de marzo de 2011

Configurar Xdebug en NetBeans

Si ya hemos instalado Xdebug en nuestro PHP (más información aquí) seguramente nos faltará un paso para utilizarlo de forma integrada en NetBeans. Para comprobarlo basta con acceder a la opción "Depurar"->"Debug Proyect" con un proyecto PHP abierto tal y como se muestra a continuación:


Si no tenemos Xdebug configurado para trabajar desde NetBeans, en la parte inferior derecha aparecerá una barra de progreso como la siguiente:


Que permanecerá durante mucho tiempo moviéndose sin ningún resultado. Mejor interrumpirlo con el botón que aparece a la derecha de la barra. Entonces, nos aparecerán indicaciones sobre los pasos que tenemos que seguir. Se trata de un mensaje como este:


Así que, en definitiva, lo que tenemos que hacer es añadir a nuestro php.ini las siguientes líneas:

xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost (o la ip del servidor Web)
xdebug.remote_port=9000

Luego, como siempre que hacemos cambios en el php.ini hay que reiniciar Apache para que la nueva configuración surta efecto.

Pequeño contratiempo
Una vez hecho todo lo anterior, al iniciar de nuevo la depuración desde NetBeans me he encontrado con un mensaje como el siguiente:


Para solucionarlo he dicho que sí y he indicado el puerto 9001 en el campo "Debugger Port" de la ventana que se abre y a la que también se puede acceder desde "Herramientas"->"Opciones"->"PHP".


Luego he hecho  lo mismo en el php.ini (xdebug.remote_port=9001) y he reiniciado Apache. Ahora ya todo funciona a la perfección.

En esta página hay documentación detallada y oficial de NetBeans sobre cómo configurar Xdebug.

¿Qué es Xdebug?

Xdebug es una extensión para PHP que proporciona un soporte muy completo para la depuración de nuestros scripts. Enumeramos continuación sus características principales:
  • Añade características avanzadas en el volcado del valor de las variables, al sobreescribir la función de PHP var_dump().
  • Las trazas de error incluyen información personalizable, y son lanzadas automáticamente cuando PHP genera un mensaje a nivel de warning, error o info.
  • Permite hacer trazas personalizables de funciones: invocaciones, valor y tipos de parámetros y valores de retorno.
  • Incluye un analizador de cobertura de código. No sólo es útil para posibles detecciones de código inaccesible sino también para conocer el alcance de nuestros test unitarios.
  • Hacer análisis de rendimiento. Detectar cuellos de botella, tiempos muertos, carga de recursos y en general, el comportamiento de nuestros script PHP con la información manejada en tiempo de ejecución. La información generada por el profiles puede ser posteriormente analizada visualmente con las aplicaciones opensource y GPL KCacheGrind (linux+KDE), o WinCacheGrind (Windows).
  • Añade la posibilidad de depuración a cualquier cliente que sea capaz de ejecutar scripts PHP y soporte el protocolo DBGp. Esto es, ofrece características de depuración remota para Eclipse PDT, NetBeans, Notepad++, Protoeditor, Komodo... ¡e incluso vim!!
  • Xdebug incluye un cliente de depuración standalone y opensource: Xdebugclient 0.9.0
Este resumen lo he tomado de esta página.

Instalación de Xdebug

Para instalar Xdebug (http://www.xdebug.org/) lo mejor es dejar que su propia Web nos indique qué fichero es el adecuado para nuestra configuración y cómo instalarlo.

Solo tenemos que pegar el fuente de un phpinfo() obtenido de nuestro sistema en http://www.xdebug.org/find-binary.php. En cuanto hagamos clic sobre el botón "Analyse my phpinfo() output" obtendremos las indicaciones.

En mi caso he obtenido lo siguiente:

Summary

Xdebug installed: no
Server API: Apache 2.0 Handler
Windows: yes - Compiler: MS VC6 - Architecture: x86
Zend Server: no
PHP Version: 5.3.4
Zend API nr: 220090626
PHP API nr: 20090626
Debug Build: no
Thread Safe Build: yes
Configuration File Path: C:\WINDOWS
Configuration File: C:\PHP\php.ini
Extensions directory: C:\PHP\ext

Instructions

  1. Download php_xdebug-2.1.0-5.3-vc6.dll
  2. Move the downloaded file to C:\PHP\ext
  3. Edit C:\PHP\php.ini and add the line
    zend_extension = C:\PHP\ext\php_xdebug-2.1.0-5.3-vc6.dll
  4. Restart the webserver

lunes, 14 de marzo de 2011

Dónde y cómo crear el fichero .gitignore

En el apartado "Ignorando Archivos" de http://progit.org/book/es/ch2-2.html se explica de maravilla cómo evitar que vayan a parar a nuestro repositorio determinados ficheros (por ejemplo módulos compilados, ficheros de backup, ejecutables, etc.).

Solo he tropezado con un par de detalles, el dónde y el cómo. Pues bien, el fichero ".gitignore" hay que crearlo en el "working directory" del proyecto y no en el directorio ".git". Respecto al cómo, apuntar que los usuarios de Windows pueden tener problemas al tratar de guardar un fichero solo con extensión y sin nombre, pero se puede hacer fácilmente desde la consola de Git con el comando "git vi .gitignore" (sobre el manejo del editor vi hay información básica en http://es.wikipedia.org/wiki/Vi).

Es fácil ver si el .gitignore está surtiendo efecto. Si creamos o metemos un fichero de los que deseamos ignorar en el directorio de trabajo y hacemos un "git status", éste no aparecerá en la lista de los "Untrucked".

sábado, 12 de marzo de 2011

Clases y objetos en PHP 5

En el modelo de objetos de PHP 5 ha habido cambios muy importantes respecto a PHP 4 y es fundamental conocerlo a fondo. ¡En Symfony absolutamente todo son objetos!

Aquí hay una completa guía en español:

Ajustando php.ini para Symfony2

He tenido que hacer algunos ajustes en el archivo php.ini por requerimiento de Symfony2. Se trata del valor de "date.timezone" de la sección [Date]. Yo le he asignado de la siguiente forma y me ha funcionado correctamente:

date.timezone= Europe/Madrid

TortoiseGit

Aunque Git dispone de un interfaz gráfico que se puede lanzar desde la consola mediante el comando "gitk", TortoiseGit nos ofrece muchas más posibilidades directamente desde el explorador de archivos de Windows. En primer lugar, con sus indicadores visuales podemos ver el estado de los ficheros y carpetas de nuestro proyecto:


Y con clic derecho disponemos de un amplio menú contextual para interactuar con Git.


Respecto a la instalación no hay mucho que decir. Es muy sencilla y no requiere ajustes posteriores, al menos por lo que he podido ver hasta ahora.

Cambiar el directorio de datos de MySQL

Por defecto, el directorio en el que MySQL guarda las bases de datos es del estilo del siguiente:

C:\Documents and Settings\All Users\Datos de programa\MySQL\MySQL Server 5.5\data

Para cambiarlo, hay que editar el archivo my.ini del directorio donde se instala MySQL y modificar el valor de datadir poniendo la ruta al nuevo directorio de datos. Yo, por ejemplo, he puesto lo siguiente

datadir="C:/MyData/MySQLData/"

Una vez hecho esto he movido el contenido de la antigua carpeta de datos a la nueva y he reiniciado el servicio MySQL.

jueves, 10 de marzo de 2011

Instalación de PHP

Según lo que se indica en esta página, Symfony2 necesita como mínimo una versión 5.3 de PHP.

Tras instalar Apache (tal y como comento en la entrada anterior) he ido a la página de descargas de PHP para Windows  y he descargado e instalado php-5.3.4-Win32-VC6-x86.msi. Éste configura automáticamente el servidor Web y por tanto resulta muy muy fácil de instalar.

IMPORTANTE:
Como hay muchas versiones a elegir, conviene visitar esta página http://windows.php.net/download/ y leer las indicaciones del apartado "Which version do I choose?" de la parte izquierda. De entrada nos dice que para Apache hay que utilizar los VC6 (no los VC9) y yo he descartado los que contienen "nts" en el nombre, ya que éstos no configuran automáticamente con Apache y además no tienen los ficheros php5apache2_2.dll necesarios para que PHP pueda trabajar como un módulo de Apache.

Por tanto si tras instalar PHP, éste no te funciona y no puedes configurar manualmente el httpd.conf de Apache porque te faltan ficheros del tipo php5apache2_2.dll,  no has elegido la versión correcta del instalador de PHP.

Instalación de Apache HTTP Server

He instalado sin ningún problema la versión 2.2.17 disponible en esta página: http://httpd.apache.org/download.cgi.

He elegido httpd-2.2.17-win32-x86-no_ssl.msi, es decir la versión "Win32 Binary without crypto (no mod_ssl) (MSI Installer)". De momento lo he hecho sin saber con certeza cuál es la versión adecuada (si es que hay alguna preferible) para Symfony2.

Solo destacar que, una vez instalado, he cambiado la carpeta raíz del servidor Web . He modificado el fichero httpd.conf de la carpeta "conf" donde se instaló Apache  modificando este valor:

DocumentRoot "C:/MyData/Source/WebServer"

Esto, lógicamente no es imprescindible. Yo lo he hecho para ajustarlo a mi particular organización del disco duro. Luego, como siempre que modificamos httpd.conf, hay que reiniciar Apache para que los cambios surtan efecto.

Instalación de herramientas para trabajar con Symfony2

Como ya voy a empezar a hacer pruebas reales con Symfony2 (ya que ya el capítulo 2 de "The Book" lo requiere) voy a necesitar de una serie herramientas. Las voy a instalar desde cero para así disponer de una instalación "en limpio" de todas ellas. Lo voy a hacer sobre Windows y van a ser las siguientes:
No todasson necesarias, pero voy a tratar de crear un entorno de trabajo lo más completo posible.

Como existe amplia información en Internet sobre el proceso de instalación de todas ellas, solo escribiré alguna nota cuando me encuentre alguna dificultad o haya algún detalle que aclarar que pueda ser útil o ahorre trabajo.

Yo prefiero la instalación individual pero, para los que prefieran hacerlo todo de golpe, existe WampServer que instalada simultáneamente muchas de estas herramientas.

Empezando con Symfony2

Después de haber dedicado varias entradas a Git para fijar al menos algunas nociones sobre él, vuelvo a Symfony2. Más que volver, empiezo, y el punto de partida es el "Quick Tour" accesible desde


Es bastante breve y va al grano. Al menos en un primer vistazo, aunque va aclarando algunos conceptos no me resulta fácil entender el fondo.

Después se nos remite "The Book" un manual más amplio sobre Symfony2 disponible en


Antes de descubrir el "Quick Tour" me había leído con detenimiento el primer capítulo "Introducción a Symfony 2 y HTTP" y creo que es un magnífico comienzo partiendo de los orígenes y recuperando la perspectiva de lo que es una petición y una respuesta vía HTTP. Por lo pronto nada que añadir, solo decir que hay muchas ganas de abordar el capítulo siguiente.

miércoles, 9 de marzo de 2011

El mejor manual de Git

Mi búsqueda de información sobre Git y algunas pruebas con el producto me han permitido escribir varias entradas sobre mis primeras experiencias con este sistema de control de versiones. También he elaborado una pequeña lista de enlaces interesantes (se encuentran en el apartado "Enlaces" del blog), pero creo que he encontrado el manual ideal. Para todo aquel que quiera un manual es español, útil, riguroso y perfectamente estructurado les recomiendo esta página: Pro Git en español.

domingo, 6 de marzo de 2011

Git - Aclarando conceptos: working directory, staging area y repositorio

Comprender la lógica de trabajo de Git requiere entender con claridad estos tres conceptos. Para ello recomiendo la lectura de esta página del fantástico libro "Pro Git" (http://progit.org/book/es/) y, en particular, del apartado "Los tres estados". De él he extraído de forma casi literal estas tres definiciones:

  • El directorio de Git es donde Git almacena los metadatos y la base de datos de objetos para el proyecto. Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otro ordenador. Es el que contiene el repositorio (repository).

  • El directorio de trabajo (working directory) es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o modificar. Se puede decir que es el que aloja físicamente los archivos del proyecto.

  • El área de preparación (staging area) es un sencillo archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación. A veces se denomina el índice (index), pero se está convirtiendo en estándar el referirse a ello como el área de preparación.

Los archivos nuevos y los modificados se "pasan" primero al área de preparación (staging area) para luego pasarlos definitivamente al repositorio. Por tanto, los ficheros temporales, ejecutables, etc. que no queremos que vayan al repositorio bastará con que no los pasemos nunca al área de preparación (mediante "git add"). Al no hacerlo, Git los ignorará totalmente.

De esta forma podemos controlar perfectamente los archivos que gestionará Git de nuestro directorio de trabajo y que formarán parte del repositorio. En general no tiene sentido, por ejemplo, que estemos guardando en el repositorio cada cambio de un ejecutable que en todo momento podemos generar con el código fuente que por supuesto sí guardamos en él.

sábado, 5 de marzo de 2011

Git para Dummies - Paso 3 - Empezando por fin

Vamos, por fin, a tratar de dar los primeros pasos trabajando realmente con Git. Para ello voy a recurrir a un proyecto ficticio sobre el que haré las pruebas. He creado en mi disco duro una carpeta llamada "MiProyecto" y dentro he creado dos simples ficheros de texto llamados "ModuloA.txt" y "ModuloB.txt" (he evitado las tildes deliberadamente) cuyo contenido es "Fuente A - Versión 1" y "Fuente B - Versión 1" respectivamente.


Ahora vamos a lanzar el Git Bash en el directorio del proyecto. Bastará con un clic con el botón derecho sobre la carpeta y elegir la opción "Git Bash". Ya tenemos la consola de Git en pantalla. Empezamos!

  • Paso 1: Creamos un repositorio local con el comando "git init". Esto creo un repositorio local vacío en una carpeta oculta llamada ".git" con una estructura como la que se muestra a continuación:

  • Paso 2: Ejecutamos "git add ." para añadir todos los ficheros del proyecto al llamado "index" o "staging area".
  • Paso 3: Ejecutamos 'git commit -m "Primera copia"' para grabar los cambios de los ficheros registrados en el "staging area" en el repositorio.
Esto es solo un pequeño "aperitivo", un ejemplo de uso de la consola de Git para, al menos, dar un idea de cómo se trabaja con él. En otras entradas iremos profundizando en conceptos, comandos, etc. que creo aclararán al que no lo sepa o haya entendido qué hemos hecho exactamente con estas tres instrucciones.

Aprovecho para recordar que desde la consola podemos obtener directamente ayuda sobre un comando determinado mediante "git help <comando>", por ejemplo "git help commit". Y si simplemente ejecutamos "git" se mostrará la lista de comandos disponibles.

Git para Dummies - Paso 2 - Git Bash - Nociones

Como se vio en la entrada anterior, tras la instalación de Git, una de las nuevas opciones de que disponemos en el menú de programas de Windows es "Git"->"Git Bash". He extraído esta definición de "Bash" de la Wikipedia:
Bash es un programa informático cuya función consiste en interpretar órdenes. Está basado en la shell de Unix y es compatible con POSIX. Fue escrito para el proyecto GNU y es el intérprete de comandos por defecto en la mayoría de las distribuciones de Linux.
(Para información mucho más detallada: http://es.wikipedia.org/wiki/Bash)

Por tanto, el nombre (Git Bash) ya nos dice mucho. Se trata de una consola desde la que ejecutar comandos de Git. El aspecto es como el de la imagen siguiente:


En esta ventana se pueden ejecutar los comandos Linux más habituales, por ejemplo ls, cd, pwd, etc. (clic aquí para una lista completa) pero la idea es ejecutar comandos de Git, como podría ser por ejemplo "git commit". Para conocer los comandos de Git basta con ejecutar "git".

Si en el proceso de instalación hemos elegido "Run Git from de Windows Command Prompt" también podemos ejecutar comandos de Git directamente desde el símbolo del sistema de Windows . En el pantallazo que sigue se ha llamado a Git desde el símbolo del sistema:


En esta ventana lógicamente lo que el sistema entiende son los comandos habituales de Windows y no los de Linux como en el caso del Git Bash pero, igualmente, para ejecutar comandos de git basta con escribirlos en la forma "git comando".

MUY IMPORTANTE: Desde la consola podemos obtener directamente ayuda sobre un comando determinado mediante "git help <comando>", por ejemplo "git help commit". Y si simplemente ejecutamos "git" se mostrará la lista de comandos disponibles.

Git para Dummies - Paso 1 - Instalación en Windows

Como el primer "dummie" total en sistemas de control de versiones, y por supuesto en Git, es el que escribe, hay que tomar estas entradas como un mero reflejo de mi experiencia desde la absoluta y total inexperiencia y desconocimiento de Git. Con el tiempo iré corrigiendo los errores que pueda en estos textos, pero espero que puedan servir al menos para ayudar a otros en algún aspecto.

Bueno, al grano. De momento sigo estos pasos:
  • Me dirijo a la Web oficial de Git: http://git-scm.com/
  • Hago clic en el enlace "Dowload" y luego en el enlace "Windows" del apartado "Download Git"
  • Descargo "Git-1.7.4-preview20110204.exe"
Al ejecutar el instalador tomo las opciones por defecto que el programa propone excepto en el primer paso. En éste elijo "Run Git from the Windows Command Prompt" porque creo que me facilitará las cosas. A continuación muestro en imágenes las tres elecciones que he hecho:




Una vez terminada la instalación, lo primero que encuentro es una nueva opción llamada "Git" en el menú de programas de Windows. Ésta  me da acceso a otras dos: "Git Bash" y "Git GUI" como se muestra en la imagen que sigue:

Imagen A

Ahora, aunque ya se intuye, habrá que averiguar qué es exactamente cada cosa.

El otro cambio que se puede percibir tras la instalación es que en los menús contextuales (al hacer clic con el botón derecho) de cualquier carpeta aparecen estas tres nuevas opciones:

Imagen B 

Vamos a ver qué es todo esto para tratar de entender lo mejor posible cómo funciona Git, pero mi idea (no sé todavía si errónea) es recurrir más adelante a TortoiseGit que parece ofrecer una forma más intuitiva y sencilla de utilizarlo.

Por lo pronto aclarar que llamar al Git Gui (Graphic User Interface for Git) desde el menú de Windows (Imagen A) o desde el contextual de una carpeta  (Imagen B) resulta totalmente indiferente. Se abre la aplicación exactamente de la misma forma. A continuación se muestra un pantallazo:


En el caso de Git Bash la cosa cambia. Si lo ejecutamos desde el menú contextual de una carpeta (Imagen B) la consola estará ya ubicada en ese directorio y si lo ejecutamos desde el menú de programas de Windows (Imagen A) se abrirá en el directorio actual del sistema, por ejemplo "C:\Documents and Settings\PCXX".

miércoles, 2 de marzo de 2011

¿Git o SubVersion (SVN)?

En cuanto a software de control de versiones para Symfony, el dilema está absolutamente claro: hay que utilizar Git. ¿Por qué? Pues porque Git es el oficial para Symfony 2. Así que Subversion descartado.

Sin duda se han decantado por Git porque éste presenta muchas ventajas. Es opensource, distribuido, no intrusivo, está disponible para Windows, Linux y Mac, etc. Y tiene una característica desde mi punto de vista especialmente destacable: ¡permite llevar un control de versiones incluso de ficheros binarios!

Dos enlaces para ir echando un vistazo:
Si se desconoce totalmente Git o los sistemas de control de versiones aquí hay unos vídeos estupendos y en español. Aunque modestos en la realización, creo que pueden resultar muy útiles para descubrir qué es Git y cómo empezar a utilizarlo. De hecho, en parte, me he inspirado en alguno de ellos para escribir algunas de las próximas entradas.

lunes, 28 de febrero de 2011

¿Symfony 1 o Symfony 2?

En el momento de escribir esta entrada, la última versión publicada de Symfony es la 1.4 (noviembre de 2009). Existe muy extensa documentación y de hecho es con la guía definitiva de la 1.2 con la que he empezado a conocer el producto y a escribir este blog, pero resulta que Symfony 2 está a punto de salir del horno y por lo visto trae  importantes cambios respecto a su predecesor. Entonces surge la pregunta: ¿es mejor empezar a conocer Symfony 1 para luego saltar al 2 o directamente empezar a trabajar con Symfony 2?.

Mi impresión es que vale la pena empezar directamente con Symfony 2. Éste, según el vídeo cuyo enlace pongo a continuación, es más sencillo de manejar, más fácil de aprender, deja atrás muchas cuestiones no del todo eficientes del 1, sustituye los plugins por un nuevo concepto (bundles) y además establece ya como "oficiales" un ORM (Doctrine) y un gestor de versiones (Git).
Aquí también se adelantan algunas características de Symfony 2:
Página oficial de Symfony 2:
Y para empezar con Symfony 2:
  • Quick Tour (es un pequeño manual que empieza desde la instalación y recorre los conceptos básicos)

domingo, 27 de febrero de 2011

Generar YAML para Doctrine utilizando MySQL Workbench

Una de las formas más sencillas de generar YAML para Doctrine y así ver casos reales y concretos, es utilizar MySQL Workbench Doctrine Plugin. Éste nos permite generar YAML desde la famosa herramienta MySQL Workbench (http://wb.mysql.com/a partir de una base de datos MySQL que ya tengamos .

Lógicamente el primer paso es instalar el mencionado plugin. Se puede encontrar en la siguiente página:

http://code.google.com/p/mysql-workbench-doctrine-plugin.

Hay que ir a la pestaña "Download" y descargar un fichero con un nombre del tipo "MySQL-Workbench-Doctrine-Plugin-x.x.x.zip", que contiene el fichero DoctrineExport.grt.lua. Ahora hay que ir a "Tools"->"Install plugin/Module File" del MySQL Workbench y tomar el fichero.

Una vez hecho esto he tenido que reiniciar la aplicación para que me aparecieran en "Plugins"->"Catalog" las dos nuevas opciones "Doctrine Export". Ahora los pasos a seguir son los siguientes:
  • Ir a "Database"->"Reverse Engineer"
  • Mediante el Wizard que aparece seleccionar la base de datos que deseemos y completar el proceso.
  • Una vez nos aparece el diagrama con todas las tablas ir a "Plugins"->"Catalog"->"Doctrine Export".
Y ya tenemos nuestros fichero .yml que podemos visualizar simplemente con, por ejemplo, WordPad .

sábado, 26 de febrero de 2011

¿Propel o Doctrine?

Una de las muchas ventajas de Symfony es que utiliza "Mapeo de Objetos a Base de datos" (ORM). Citando la guía:
Las bases de datos siguen una estructura relacional. PHP 5 y Symfony por el contrario son orientados a objetos. Por este motivo, para acceder a la base de datos como si fuera orientada a objetos, es necesario una interfaz que traduzca la lógica de los objetos a la lógica relacional. Esta interfaz se denomina "mapeo de objetos a bases de datos" (ORM, de sus siglas en inglés "object-relational mapping").
Aunque en la guía se indica que Propel es el ORM por defecto de Symfony, parece que ha sido eclipsado últimamente por Doctrine. De hecho éste último tiene varias ventajas respecto al primero como se indica en páginas como esta: http://www.hasheado.com/doctrine-vs-propel.html.

Hay una comparación "oficial" en esta otra página: http://trac.symfony-project.org/wiki/ComparingPropelAndDoctrine.

Mi primera impresión por la información que he encontrado es que Doctrine es la mejor opción. Además, solo el hecho de que esté basado en YAML y no en XML creo que ya representa una ventaja muy importante a la hora de trabajar. YAML es mucho más inteligible para un humano que el XML.

Pero dejando de lado opiniones e impresiones... ¡ojo! ¡Doctrine es el ORM oficial para Symfony 2!.

¿Qué es Symfony?

Para el que no tenga claro qué es Symfony en realidad, reproduzco a continuación el apartado "Symfony en pocas palabras" de la guía. Creo que da una idea clara de qué es y qué podemos esperar de él.
Un framework simplifica el desarrollo de una aplicación mediante la automatización de algunos de los patrones utilizados para resolver las tareas comunes. Además, un framework proporciona estructura al código fuente, forzando al desarrollador a crear código más legible y más fácil de mantener. Por último, un framework facilita la programación de aplicaciones, ya que encapsula operaciones complejas en instrucciones sencillas. 
Symfony es un completo framework diseñado para optimizar, gracias a sus características, el desarrollo de las aplicaciones web. Para empezar, separa la lógica de negocio, la lógica de servidor y la presentación de la aplicación web. Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación. El resultado de todas estas ventajas es que no se debe reinventar la rueda cada vez que se crea una nueva aplicación web.
Symfony está desarrollado completamente con PHP 5. Ha sido probado en numerosos proyectos reales y se utiliza en sitios web de comercio electrónico de primer nivel. Symfony es compatible con la mayoría de gestores de bases de datos, como MySQL, PostgreSQL, Oracle y SQL Server de Microsoft. Se puede ejecutar tanto en plataformas *nix (Unix, Linux, etc.) como en plataformas Windows. A continuación se muestran algunas de sus características:

  • Fácil de instalar y configurar en la mayoría de plataformas (y con la garantía de que funciona correctamente en los sistemas Windows y *nix estándares).
  • Independiente del sistema gestor de bases de datos.
  • Sencillo de usar en la mayoría de casos, pero lo suficientemente flexible como para adaptarse a los casos más complejos.
  • Basado en la premisa de "convenir en vez de configurar", en la que el desarrollador solo debe configurar aquello que no es convencional.
  • Sigue la mayoría de mejores prácticas y patrones de diseño para la web.
  • Preparado para aplicaciones empresariales y adaptable a las políticas y arquitecturas propias de cada empresa, además de ser lo suficientemente estable como para desarrollar aplicaciones a largo plazo.
¡Las expectativas son realmente fantásticas! Con una herramienta semejante, se le puede dar un vuelco total a la forma de crear aplicaciones con PHP porque, para el que no lo tenga claro todavía, Symfony no es solo un framework desarrollado en PHP, es un framework para desarrollar en PHP.

Y algo MUY IMPORTANTE: aprender a utilizar Symfony no es como aprender un nuevo lenguaje de programación, sino que consiste en aprender a tomar las decisiones correctas para desarrollar las aplicaciones de forma más efectiva.

Manual de referencia

En español hay una guía de gran calidad. Además de completa y rigurosa está maravillosamente escrita y traducida. Se encuentra disponible tanto en formato Web como en PDF:


Este manual consta de 19 capítulos muy bien estructurados en los que se aborda Symfony de forma progresiva y partiendo de cero. Su lectura es imprescindible para los que desconocemos este framework y tenemos que entender qué es realmente y cuál es su filosofía de trabajo.

Nunca es tarde...

En el mundo "real" la programación casi siempre se aleja de lo ideal. Los plazos, los costes y otros muchos factores acaban por conducir los desarrollos por derroteros poco deseables que finalmente desembocan en aplicaciones innecesariamente complejas y farragosas, difíciles de mantener y cargadas de "fardos" de los que no hay manera de deshacerse y que condicionan para siempre su futuro.

Creo que,  no pocas veces, muchos de los que nos dedicamos al desarrollo sufrimos o hemos sufrido esta situación. Como nunca es tarde, he tomado la decisión de sumergirme en el mundo de Symfony para dar por fin un giro a los procedimientos de desarrollo de mi empresa. No creo que me resulte fácil a estas alturas de mi vida y teniendo en cuenta que con este framework parto de cero, pero ése es precisamente el reto y lo que da sentido a este blog. Voy a tratar de plasmar en él toda la información que pueda sobre los dilemas y dificultades que me encuentre para así ayudar, quizás, a algunos a facilitarles el camino y para quién sabe si recabar el apoyo de otros para solventarlas.

Bueno, aquí empieza la aventura y aquí están las puertas de entrada:
Desde luego las perspectivas son fantásticas.