Appfuse y el talón de Aquiles del desarrollo de Software.

En esta entrada hablaré de un libro de historia interesante y de mi experiencia con Appfuse (www.appfuse.org) y como aquel libro de historia me ha hecho reflexionar.

He terminado recientemente de leer "El Economista camuflado", libro que ha vuelto a despertar en mí la sensación de tener muchas ganas de aprender leyendo de cosas que no tengan que ver con software - sensación que no experimentaba desde "El último Catón" [Matilde Asensi]. En el intertanto han pasado varios libros de software que recomiendo ferviéntemente: "The pragmatic programmer" y la serie de los libros "Head First", en especial el de patrones de diseño.

Comentaba que he terminado de leer "El economista camuflado" por que a continuación de dicho libro he comprado otro que me ha parecido muy interesante, su nombre es "El talón de Aquíles" [Cesar Vidal] y cuenta sobre cuales han sido las debilidades de personajes de la historia que los han hecho sumirse en grandes derrotas - todo gracias a su talón de Aquíles. Interesantes antecedentes históricos que me hicieron pensar en cuál es el talón de Aquíles de nosotros los ingenieros de software.

Hablar de cuales son las debilidades que padecemos los ingenieros de software puede tomar bastantes horas, incluso hay asignaturas completas que rezan sobre las causas de la crisis del software, o de porqué el software carece de una visión industrial desde su concepción. Desde mi punto de vista creo que el talón de Aquiles de esta profesión es que carece desde un principio de la conexión entre la teoría y la práctica, ¿Cuántos profesores han hecho un mapping de persistencia con Hibernate?, ¿Un paginador?, ¿Han validado la vista W3C?, ¿Una estrategia de búsqueda?, ¿Objetos en caché? salvo casos destacados. Así pues nos vemos enfrentados a un mundo de clientes que esperan resultados concretos - no podemos responder a las tareas de un proyecto con ejercicios mentales.

Desde algunos años existen Frameworks de desarrollo de software que vienen precisamente a aportar lo industrial pues orquestan las piezas de una aplicación aportando los mecanismos necesarios para que todo funcione apropiadamente y obviamente reutilizando bibliotecas usadas millones de veces a lo largo y ancho del mundo. A pesar de todos estos beneficios me impresiona la cantidad de personas ligadas al mundo del software que conoce muy poco de estos temas; personalmente fuí muy ignorante de esto hasta que aprendí Ruby On Rails hace un par de años.

Existen frameworks para todos los gustos y tecnologías, de los que he utilizado y/o visto puedo hablar con propiedad de dos de ellos: Symfony para php5 y Spring para Java. En el encabezado de este post señalaba que hablaría de Appfuse, pues bien Appfuse (www.appfuse.org) es un organizador de distintas herramientas utilizadas para construir software con java; en términos concretos puedes elegir un arquetipo de appfuse y en un par de minutos tendrás configuradas tus herramientas favoritas listas para comenzar a desarrollar tu aplicación.

La configuración de appfuse que utilizo es Spring + Hibernate, a continuación les doy 6 razones para desarrollar software con Appfuse:

  1. Gestión de usuarios: Desde el momento de la primera ejecución appfuse provée un sistema de gestión de usuarios que incluye login, creación, roles, recuperar contraseñas. En fin todo lo que nos demandaba tiempo y era aburrido. ¿Alguien se ha divertido haciendo las clases para escribir cookies y validar sesiones?.
  2. Plugin de generación de código: Una vez diseñada tu base de datos con su integridad referencial por supuesto, basta ejecutar una orden para que se genere el código - si eres bueno diseñando bases de datos estarás encantado. Esta generación de código escribe las clases con anotaciones JPA que permitirá conectar tu modelo orientado a objetos con la persistencia (Tengo un post relacionado llamado orientación de objetos v/s Bases de datos).
  3. Generación de CRUD: Si la aplicación va de muchos "Crear/Editar/Borrar/Mostrar" de seguro esto te solucionará muchos de tus problemas. No sólo se genera el código para el CRUD si no que los test y datos de prueba. Evidentemente no te puedes quedar sólo con lo que te generara - si necesitas customizar lo generado es muy fácil de refactorizar - pues Appfuse crea managers y Daos genéricos que luego puedes fácilmente reemplazar por tus clases.
  4. Jetty: Appfuse incluye un mini-tomcat por decirlo simple, desde el proyecto ejecutas mvn jetty:run-war y luego a http://localhost:8080 - No deploy need! - además no levanta el servidor si tu appz no pasa los test (Testing driven developmente es absolutamente necesario a estas alturas).
  5. Utilizas el poder y la magia de las herramientas, la inyección de dependencia de Spring es un concepto que voló mi cabeza al descubrirlo - no cabe más que decir que si los productos por sí solos son exitósos, imagínatelos coordinados trabajando al servicio de tu cliente.
  6. Dejo lo más importante para el final: La respuesta a tus dudas es Matt Ribbles - Appfuse cuenta con una de las mejores listas de correos que he participado - todas las veces que he preguntado algo es Matt Ribbles, creador de appfuse, quien personalmente contesta dándote exáctamente la información que necesitas. O séa que mejor.

Y puesto que la ingeniería de software es una Lemmingería (Alan Davis ironizaba al respecto) les cuento lo que no me ha gustado de appfuse:
  1. La curva de aprendizaje: Se tarda mucho en entender de que vá el tema, desde el DaoImpl al DaoInterface, del ManagerImpl al ManagerInterface, de los manager y Daos genéricos, del dispatcher servlet, de los alias de vistas y vista resolver, del initBinder del controlador, del controlador multiaction ..... hay mucho, mucho que aprender a entender como se relacionan. En 4 fin de semanas puedo decir que ví claridad.
  2. El riesgo de lo automático existe aquí - pero muy poco: Me ocurrio que en unos test, Spring inyectaba por nombre el objeto necesario automáticamente, esto funcionaba perfecto hasta que puse dos aplicaciones en el mismo workspace y cambié de portatil - no funcionó más. Luego de eso tuve que buscar en todo el Spring in Action para resolver el problema.
  3. Aprender todos los mecanismos para ver claridad, personalemente no soy muy bueno con las capas de presentación - me gusta más el tema puro de patrones en la parte del modelo y controlador, pero me he visto obligado a pasar horas revisando los jsp y sus tags.

Para concluir, les hago una invitación a usar frameworks y que si ya los usan a buscar otros para mejor continuamente para vencer nuestro talón de Aquiles - Mi próximo desafío se llama Grails.

Hasta pronto!.