Recomendados
Recomendados
Más contenido relacionado
Similar a Caso práctico II: symfony en la gestión de un centro de computación avanzada (ceta-ciemat.es) - decharlas
Similar a Caso práctico II: symfony en la gestión de un centro de computación avanzada (ceta-ciemat.es) - decharlas (20)
Último
Último (20)
Caso práctico II: symfony en la gestión de un centro de computación avanzada (ceta-ciemat.es) - decharlas
- 1. Castellón - 5 y 6 de Julio 2010 – Universitat Jaume I organizan patrocinan colaboran Jornadas Symfony 5 y 6 de julio 2010 Universitat Jaume I, Castellón http://decharlas.uji.es/symfony
- 2. Caso práctico: Symfony en la gestión de un centro de computación avanzada César Suárez, www.ceta-ciemat.es Jornadas Symfony 5 y 6 de julio 2010 Universitat Jaume I, Castellón http://decharlas.uji.es/symfony
- 3. sesión patrocinada por www.ceta-ciemat.es Jornadas Symfony http://decharlas.uji.es/symfony
- 4. ¿Quiénes somos? Jornadas Symfony http://decharlas.uji.es/symfony
- 5. ¿Dónde estamos? Jornadas Symfony http://decharlas.uji.es/symfony
- 6. ¿Dónde estamos? Jornadas Symfony http://decharlas.uji.es/symfony
- 7. ¿Dónde estamos? Jornadas Symfony http://decharlas.uji.es/symfony
- 8. ¿Dónde estamos? Jornadas Symfony http://decharlas.uji.es/symfony
- 9. ¿Dónde estamos? Jornadas Symfony http://decharlas.uji.es/symfony
- 20. CMDB: Resultado Jornadas Symfony http://decharlas.uji.es/symfony
- 21. CMDB: Resultado Jornadas Symfony http://decharlas.uji.es/symfony
- 22. CMDB: Resultado Jornadas Symfony http://decharlas.uji.es/symfony
- 23. CMDB: Resultado Jornadas Symfony http://decharlas.uji.es/symfony
- 27. UAWP: Resultado Jornadas Symfony http://decharlas.uji.es/symfony
- 28. UAWP: Resultado Jornadas Symfony http://decharlas.uji.es/symfony
Notas del editor
- Primero agradecer a la organización el esfuerzo que han hecho para cuadrar horarios y hacernos un hueco como ponentes. Como ha sido un dia largo, tampoco me quiero extender mucho. En nuestro caso vamos a explicar nuestras experiencia con el framework durante el desarrollo de diversas herramientas hechas en el CETA-CIEMAT. Pero antes de nada vamos a ponernos en contexto de la naturaleza del centro, para comprender el contexto de nuestros casos prácticos.
- Tantas siglas significan: CETA, Centro Extremeño de Tecnologías avanzadas, en cuyas características ahondaremos más adelante. Se trata de un centro de CIEMAT, Centro de Investigaciones Energéticas Medio Ambientales. Organismo autónomo al Ministerio de Educación y Ciencia, centrado en la investigación, especialmente en materias de energía y medio ambiente (como su propio nombre indica).
- El CETA-CIEMAT se encuentra en la ciudad de Trujillo, a unos 40 KM de Cáceres., como se puede ver en el mapa adjunto, dentro del conventual de San Francisco, un lugar bastante peculiar para albergar un centro centrado en la investigación.
- Y aquí se pueden ver algunas fotos.
- Y aquí se pueden ver algunas fotos.
- Y aquí se pueden ver algunas fotos.
- Y aquí se pueden ver algunas fotos.
- Datos curiosos de nuestro CPD.
- Cuáles son los objetivos del centro? En un principio nuestro centro actualmente está centrado en las redes GRID, ya sea a nivel de investigación, ofreciendo servicios o desarrollando sistemas que se beneficien de este tipos de redes. Ofrecemos toda la potencia de la GRID (para quien no lo sepa, a grandes rasgos y sin ser muy ortodoxos a nivel técnico), se basa en redes de varias computadoras que comparten sus capacidades de cálculo y almacenamiento para alcanzar potencias similares a los de una supercomputadora a un coste más bajo). No sólo ofrecemos acceso a las redes GRID en las que participamos, sino que investigamos las capacidades y uso de este tipo de tecnología a todos los niveles, no sólo a nivel científico que es el más habitual, y también desarrollamos aplicaciones que hacen uso de la potencia de la GRID. Como centro, estamos abiertos a todo tipo de colaboraciones con cualquier institución.
- Todos estos objetivos se fundamentan en varios valores (o principios), que vienen a conformar la filósofía del centro, teniendo en cuenta su naturaleza pública. El principal es buscar el interes social y el bienestar de los ciudadanos a través de las tecnologías de la información y la comunicación, y hacer estas lleguen a todo el tejido social. De nuevo recalcar que todo esto creemos que sólo es posible buscando colaboraciones y sinergias con otras instituciones, y añadir que creemos que la clave de todo esto pasa por el uso del software libre.
- Como decía, nos encargamos dentro del centro en la investigación, diseño y desarrollo de aplicaciones software. Principalmente usamos Java, y alguna de sus tecnologías relacionadas como JSF. Nuestros desarrollos se pueden dividir en 2 tipos: El primero aplicaciones relacionadas con las redes GRID, lo que incluye el porting de aplicaciones «normales» para que se beneficien de este tipo de redes. Nuestro proyecto principal es DRI (Digital Repositories Infraestructure), una plataforma de repositorios digitales, capaz de almacenar contenido digital en la GRID. Actualmente de este sistema se beneficia el Archivo Historico de Trujillo, o una colaboración con la universidad de Oporto para un repositorio de mamografías. De momento toda la plataforma está escrita en Java, y todos los clientes en Java. Al final, volveremos a esto brevemente. Aparte de los proyectos relacionados con la GRID, la unidad desarrolla aplicaciones internas para la unidad, con la idea de ayudar al resto de unidad del diagrama anterior. Entre estas aplicaciones, dos son las que nos ocupan, y que están centradas en la administración desde nuestro centro como centro de computación avanzada. Dichas aplicaciones las comentaremos a continuación, las razones que nos llevaron a usar Symfony, y que problemas y benificios ha conllevado su uso.
- Nuestra aplicación se trata de un CMDB, una aplicación para llevar el inventariado de máquinas del centro, y la generación de ficheros de configuración. Como somos muy originales, nuestra herramienta se llama «cmdb» a secas. En centros con tantos elementos a la red, no es mantenible generar «a mano» los ficheros de configuración DNS o DHCP. Por ejemplo, la última vez que miré la herramienta, habría 783 elementos, entre máquinas físicas, virtuales, elementos de red… Nuestra herramienta a parte de generar los ficheros de configuración, es capaz de mandar estos a los servidores correspondientes y reiniciar los servicios. De tal forma, con un par de clicks, el administrador puede poner en orden la estructura de red del centro. Anteriormente existía un CMDB programado en Ruby, pero que se había quedado corto de funcionalidad. Además la gente de administración de sistemas no estaban nada contentos con Ruby, y querían algo sencillo, fácil de desplegar y mantener. Básicamente querían algo desde cero, y MUY importante, que mantuviese todos los datos coherentes. La anterior herramienta no tenía ningun tipo de validador en los formularios de añadir o editar, y eso provocaba que gracias a fallos humanos se almacenasen datos problemáticos: Ips mal definidas, nombres de host repetidos, valores incoherentes… Mucho tiempo de desarrollo de la herramienta se ha pasado añadiendo todo tipo de validadores (luego veremos algunos ejemplos), e incluso facilidades incrustadas en ellos, como buscadores de Ips libres dentro de una VLAN, o de MACs libres para máquinas virtuales. Este proyecto supuso nuestra primera experiencia com symfony, ya que ninguno teníamos experiencia previa en este framework (incluso en ningun framework web similar).
- Teniendo en cuenta, todo esto y algunas razones que iremos explicando, hubo una serie de datos que nos hicieron plantearnos el uso del framework. Primero necesitabamos algo fácil y sencillo de mantener. Nos dijeron que querían algo sencillito, que funcionase en un servidor con un apache, php y mysql, porque a ellos les resultaba más familiar en el caso de migrar la herramienta de máquina (por ejemplo). Obviamente teníamos la necesidad de tener algo que nos ayudase a la hora de generar formularios, y más concretamente sus validadores, y a priori, el de symfony nos daba esa ayuda, que además nos dotaba gran flexibilidad de personalizar nuestros formularios a nuestro gusto. Más orientados a la hora de desarrollar, están las 3 últimas causas. Primero que esté basado en el patrón de diseño modelo-vista-controlador, que separa la parte del código de datos, la de negocio, y las vistas, lo que nos aseguraba como resultado un sistema sostenible y extensible, cosa muy importante, ya que una de las razones principales de desechar el anterior CMDB fue esta. Otra cosa muy importante, y que nos animó a usar Symfony es la documentación que tenía, y que además era alabada en todos los análisis que leímos. Y por supuesto que nos ofreciese ayuda en otros aspectos del sistema, como un framework para acceder a los datos de nuestra base de dataos facilmente como Propel, o un framework Javascript como Protottype. Con todos estos datos, y un poco a lo loco, comenzamos nuestra andadura con symfony.
- Bueno, en los primeros ciclos de desarrollo ya apreciamos que en algunas cosas no nos habíamos confundido. Efectivamente era fácil de instalar, desplegar y configurar. Con symfony project:freeze (creo que ya obsoleto, no?), la propia herramienta convertía nuestra «carpeta» de desarrollo en un paquete listo para desplegar con un simple copia-pega. Incluso, en el centro tenemos como parte de nuestra metodología el uso de «ant» (una herramienta de automatización de tareas hecha en java, y por tanto, multiplataforma), teníamos programados rapidamente nuestras rutinas con las que podemos preparar nuestro proyecto y desplegarlo con un solo comando. Tambien vimos que a la hora de configurar nuestra herramienta, todos los ficheros de configuración están en formato YAML, facilmente interpetables hasta por gente sin conocimientos técnicos de ningun tipo. En dos ficheros muy localizados se puede concentrar casi toda la configuración de nuestra herramienta, tanto la config de la bd, como la propia de la herramienta. La documentación, al final resultó excelente, y muy abundante. Libros de primeros pasos, de referencia, tutoriales, … Todo sabiendo conjugar los conceptos teoricos como partes prácticas (DESTACAR JOBEET). Y también disponible en multitud de idiomas, incluido una buena traducción en español. Todo online o en PDF bien maquetado para impresión. Y casi lo más importante: gratis. A destacar su comunidad tan activa, y que la documentación está siempre actualizada, sobretodo cuando la gente de symfony tiene a bien lanzar nuevos libros que enriqucen lo ya existente. Y otra cosa que pudimos confirmar de nuestras suposiciones iniciales, es que el framework de formularios era verdaderamente potente. Altamente personalizable, tanto en logica como en vista. El sistema de validadores es totalmente personalizable, dando una flexibilidad casi ilimitada a la hora de validar nuestros validadores.
- Mas cosas que nos gustaron. Sobretodo a la hora de generar código de buena calidad. Primero su estructura de directorios. SF se basa mucho en una compleja, y amplia estructura de directorios a la hora de estructurar su código. Ahora buen, una vez que te acostumbras, eres capaz de llegar a cualquier parte de tu codigo en un periquete, con la ventaja de estar todo MUY organizado. Se acabo lo de no acordarse donde estaba tal clase, o tal librería. Facilidad a la hora de generar tests unitarios y funcionales para asegurar el funcionamiento con la herramienta, de manera sencilla. Auto cargado de librerías, que funciona genial. Se acabaron las aplicaciones rotas porque se olvido incluir una librería. Helpers (pequeñas funciones) creados para ayudarnos a hacer las tareas más tediosas más fáciles, como generar links a otras partes de la herramienta, meter una imagen en una vista, hacer llamadas AJAX sencillas, crear una paginación, … Sistema de generación de la parte de la vista muy modulable, de tal forma que impide que haya que programar una y otra vez los mismos elementos de la interfaz. Se ahorra tiempo, fallos, y código repetido. Luego la barra de depuración que tiene, de tal manera que siempre que la quedemos activadas, desde el mismo navegador, podamos ver logs, variables de sistema, mediciones de tiempo, consultas lanzadas contra la BD, … Luego también es un framework muy anclado a las nuevas características que trajo PHP5. Ya no es que te deje usarlo, es que lo aprovecha al máximo en su core.
- Pero no todo es bueno. Symfony tiene una curva de aprendizaje costosa. Propone muchos conceptos nuevos para aquel que nunca ha usado un framework web mvc. Aunque la docuemtanción es buena, al ser tan extensa, y variada a veces es difícil encontrar algunos detalles. Es algo que hay que tener en cuenta. Con Symfony cuesta arrancar, por mucho PHP que sepas, PHP es sólo el medio, toda la filosfía de desarrollo que hay detrás es muy distinta si no se tiene experiencia previa. Vale, el framework de formularios es potente. Es flexible. Puedes hacer lo que quieras con él. Pero eso tiene un precio, y es que es complicado. Puede parecer en la primera toma de contacto fácil, poruqe lo básico es muy fácil, pero en cuanto quieres complicar algo las cosas los problemas empiezan a suceder. Actualmente, y a pesar de la experiencia (que no me considero ningun experto), todavía me quedo a veces atascado para hacer alguna cosa con los formularios y/o validadores. Que use versiones tan avanzadas de PHP no siempre es bueno, ya que por temas de administración, a veces no se puede tener la versión de PHP que nos gustaría en los entornos de desarrollo, test o producción. Por ello, tuvimos que empezar a usar sf1.1, aunque ya estuviese el 1.2 disponible. En el momento de empezar a desarrollar, tampoco existía ningun entorno de desarrollo medianamente competente que soportase a symfony, lo que significa a renunciar a muchas facilidades que frameworks modernos como netbeans o eclipse dan.
- Pero bueno, al final, tras un tiempo de desarrollo, creemos que las ventajas superaron a las desventajas. El código resultable actual es sólido, está bien organizo, es sencillo y por tanto es mantenible. Además, según está organizado symfony (patrón MVC), es muy fácil refactorizar partes sin afectar al resto. El framework de formularios, a pesar de las peleas que hemos tenido con él , creo que hemos conseguido domarlo, y actualmente hemos creado formularios con validadores bastante complejos, sólidos, y bastante desacoplados, y por tanto reutilizables. Incluso la estricta estructura de directorios no resultó ser tan inflexible y resultó ser personalizable, lo cuál fue muy util para adecuar nuestros proyectos a la estructura que nuestros proyectos software tienen en los repositorios SVN. En definitva, 6 releases puestas en produción con pocos sobresaltos, que han desembocado en una herramienta, estable, ampliable y modificable.