La verdad es que era algo reacio a poner este título al post, por lo manido del tema y porque no es del todo cierto. Pero seguro que todo el que lo lea tendrá claro de lo que tratan estas lineas.
Hace ya casi dos años evalué la conveniencia de utilizar para nuestros proyectos un “framework” de desarrollo que nos proporcionara un nivel de productividad mayor que el que teníamos en la programación de aplicaciones web de una complejidad media.
Hasta entonces desarrollábamos este tipo de aplicaciones con PHP y un marco de trabajo propio basado en el paradigma MVC. Para aplicaciones de más envergadura utilizábamos, y seguimos haciéndolo, Java. Con una mezcla de Struts 2 + Hibernate + diversas librerías que no viene al caso detallar.
Dado que uno de los requerimientos en aquel entonces era que el lenguaje fuera multiplataforma y la fama de RoR (Ruby on Rails) ya era muy importante decidí tenerlo en cuenta junto con otras alternativas en PHP.
El caso es que Rails me cautivó y decidimos desarrollar un par de proyectos reales con este marco. Los principios fueron duros porque no es lo mismo seguir el típico ejemplo del screencast para crear un blog en 15 minutos, que no deja de ser sorprendente, que realizar un proyecto real.
A pesar de la alta productividad que proporciona Rails, había que aprender un lenguaje nuevo (ruby) y mucha de la “magia” de RoR quedaba algo oculta. Pero finalmente superamos esa fase y gracias a algunos plugins de Rails llegamos a conseguir un nivel de productividad verdaderamente interesante. Bien es verdad que a veces abusando del scaffold.
Finalmente hemos desarrollado unos cuatro proyectos, de los cuales dos tienen una envergadura media mientras que otros dos son más bien sencillos.
El problema viene cuando tienes que instalar estos proyectos en un servidor virtual linux de los habituales. Aquí es donde te encuentras con la primera barrera.
La gran mayoría de servidores virtuales españoles ni tan siquiera dan la opción de utilizar RoR. Y en cuanto a los americanos, el que usamos lo permite pero sin utilizar fcgi. Para el que no sepa de qué va, esto obliga a utilizar Rails en Apache como un cgi normal, de tal manera que cada petición a la aplicación supone que el servidor http tiene que cargar el intérprete Rails y ejecutar el script… es decir inadmisible para una aplicación en producción.
Tan es así que en últimamente habíamos relegado a Rails para aplicaciones ejecutadas en servidores en los que teníamos permisos totales de configuración y para pequeños administradores de catálogos web en los que no importaba demasiado la velocidad.
El caso es que hace unas semanas decidí reevaluar mi decisión de hace unos años y revisé algunos de los “Rails emulators” escritos en PHP, ya que es un estándar en cuanto a lenguajes soportados por servidores virtuales Linux.
La verdad es que actualmente existen muchos frameworks para desarrollar con PHP, y entre los más conocidos he revisado Symfony y CakePHP. Symfony es potente, pero me pareció que necesitaba demasiado fichero de configuración a lo XML. Esto me recordaba demasiado a los proyectos Java en los que pasas demasiado tiempo configurando. Por lo que decidí probar CakePHP, aparentemente más sencillo.
Así que esta semana he estado probando Cake en dos proyectos reales muy simples y no me ha decepcionado.
En un primer vistazo es una copia de la plataforma de Rails en cuanto a ubicación de ficheros, evidentemente basado en paradigma MCV, filosofía DRY, etc. La filosofía de que todo funciona por convenio y únicamente cambias lo que quieres que funcione de otra forma te ahorra mucho tiempo.
Y, aunque no he he llegado a utilizar la generación de código por consola, porque al principio quería estar muy pegado al código, me ha parecido que me aportaba la productividad que buscaba, flexibilidad PHP y posibilidad de instalar la aplicación en cualquier servidor.
Como todavía no conozco la herramienta al 100% no voy a publicar ningún ejemplo pero baste decir que una administración CRUD de una tabla de datos sin tener ni idea de la plataforma me costó unos diez minutos de montar incluyendo descargar el proyecto y leer el tutorial. La documentación es más que útil y únicamente hay que tener en cuenta la versión con la que se trabaja. También es cierto que la experiencia RAILS ayuda mucho ya que es muy parecido.
Posiblemente si alguno de los que lee este post viene del mundo Microsoft se preguntará de qué estoy hablando, pero ya se sabe que hablamos otro idioma y utilizamos palabras raras como multiplataforma, soporte colectivo, etc. Que nadie se mosquee que no va con mala intención 
