martes, 26 de febrero de 2013

Notas Destacadas - Febrero 2013

  • Todas las Demos de D3.js en un único documento: D3 es la librería de gráficos para JavaScript que está dando de qué hablar en este 2013. Esta librería no sólo tiene demos asombrosas (algunas tan creativas que parecen salidas de una página de experimental gameplay o pensamiento lateral), además es super minimalista. Con muy poco código podemos tener gráficos tan flasheros como éste o éste.
  • Post simple sobre EasyCriteria: Interesante: "JPA Criteria debería ser simple", reza el título del post. ¡Amén! La API Criteria de JPA 2.0 es un infierno. Quizá frameworks como éste ayuden a simplificar el estándar en versiones futuras de Java EE.
  • Niveles de Calidad: El agujero en las metodologías de software: Un artículo en PDF en español sobre Calidad de Software. No lo he leído todavía, pero viniendo de JavaHispano creo que vale la pena darle una leída. Por ahora lo conservo en mis Bookmarks.
  • Introducción a Conceptos de Java EE: Post de Java Code Geek muy conciso y claro que puede servir como diccionario de las principales subespecificaciones de Java EE 5 y Java EE 6, mientras esperamos que se lance Java EE 7.

  • Nuevas versiones de Tomcat y de Hibernate: Noticia no menor ya que nos recuerda que ambos proyectos siguen bien vivos. Se trata de la versión 7.0.37 de Apache Tomcat y la 4.1.10.Final de Hibernate ORM.

sábado, 16 de febrero de 2013

ICTINUS


Esta semana ha sido corta aquí en Argentina pero fructífera, ya que Epidata Consulting llevó a cabo el tercer encuentro de arquitectos de software llamado ICTINUS, en honor al arquitecto griego de la segunda mitad del siglo V a.C., vinculado a las obras del Partenón, el Teleterion y el templo de Apolo.

El evento convoca a profesionales expertos en Arquitectura de Software para promover, a través del diálogo, el intercambio de ideas y experiencias sobre los temas que atraviesan la arena de esta disciplina en Argentina y en el resto del mundo.

El primer encuentro se realizó el 21 de agosto de 2012 y los temas tratados fueron:
  • Integración Arquitectura con Desarrollo: formas de reconciliar ambas áreas en grandes organizaciones. ¿Se debe programar en Arquitectura? ¿Existen los arquitectos de soluciones? ¿Un área de Arquitectura debería actuar como policía del área de Desarrollo? Escenarios de Calidad.
  • Movimiento NoSQL: experiencias aquí en Argentina con bases de datos no relacionales y sistemas de archivos distribuidos: Hadoop, Cassandra, MongoDB, Infinispan. ¿Cómo montar un data grid distribuido con redundancia? ¿Hasta qué punto es posible mantener la consistencia en memoria?
El segundo encuentro se realizó el 28 de septiembre de 2012 y los temas tratados fueron:
  • 99.99% Fault Tolerance: ¿Cómo lograr tan alta tolerancia a fallos en los ecosistemas altamente heterogéneos y distribuidos de las empresas de hoy? Replicación, particionamiento, data centers distribuidos geográficamente, caché distribuida. ¿Escala la comunicación sincrónica? Monitoreo. Topologías. ¿Cómo lidiar con aplicaciones que no soportan replicación ni particionamiento?
  • Soporte Últimas Tecnologías: formas estratégicas de lidiar con el avance de la tecnología: nuevas plataformas, nuevos frameworks, nuevos requerimientos. ¿Cómo mantener a un equipo de investigación o un área de I+D en una empresa y transmitir los conocimientos de forma ágil a los equipos de los proyectos? ¿Cómo seleccionar las plataformas que soportarán las soluciones? ¿Cómo manejar un modelo de gerencia con partners bien especializados? Prototipos, pruebas de concepto, demos.
Luego de un período de vacaciones, volvimos a retomar ICTINUS este miércoles 13 de febrero de 2013 con los siguientes temas:
  • Arquitectura y Diseño Simple: tema bastante abierto que nos llevó a preguntarnos realmente qué es la Arquitectura de Software, qué tareas y responsabilidades abarca. ¿El Diseño y la Arquitectura son disciplinas separadas? ¿Hasta dónde llega el Arquitecto y dónde comienza el Diseñador en la construcción de una solución? ¿Qué diferencias hay entre modelar la arquitectura de un proyecto y la arquitectura de una plataforma? ¿Cómo la elección de un framework puede condicionar la arquitectura de una aplicación? Arquitectura corporativa, la Arquitectura como área de una empresa, injerencia del área en el desarrollo de los proyectos. Capas: Plataforma --> Building Blocks --> Paquetes de Modelo de Dominio. ¿A arquitectura compleja diseño simple?
  • Pruebas de Stress: ¿Qué rol debería hacer las pruebas de stress en los proyectos? ¿Quién las ejecuta? ¿Cómo se escalan? ¿Cómo estresar un entorno productivo altamente heterogéneo y distribuido? ¿Cuándo deberían realizarse y ejecutarse: al comienzo del proyecto, al final, en el medio, de forma continua junto con las demás pruebas de unidad y de integración?
  • PaaS: Platform as a Service: ¿Qué mercado hay en Argentina? ¿Es el futuro? ¿Son las nubes privadas la bala de plata para las empresas? ¿Qué aplicaciones se pueden subir a la nube? ¿Cuánto esfuerzo demanda? ¿Qué productos tenemos hoy?
La siguiente reunión será en dos meses aproximadamente. Votaremos los nuevos temas que se traten o podremos regresar a algunos de los ya tratados. La idea es compartir y debatir, compartir un espacio de conocimiento y que todos podamos seguir aprendiendo.

El simple hecho de proponer temas es una forma de colaborar. Contar cómo lo resolvemos, o simplemente decir que tenemos el mismo problema, son formas de colaborar. Nadie espera llevarse "la solución", sino simplemente ideas, puntos de vista, experiencias positivas y negativas.

ICTINUS cuenta con el apoyo de Kleer, empresa especializada en metodologías de trabajo, cumpliendo el rol de facilitador y coordinador en cada encuentro.

sábado, 9 de febrero de 2013

Notas Destacadas IV

¡Hola a todos, queridos lectores! Espero que estén disfrutando este fin de semana. Esta semana y la pasada hubieron noticias interesantes, que tienen que ver sobre todo con nuevas releases de frameworks importantes:

  • Vaadin 7.0.0: Así es, señores: Nueva release estable de este gran framework Java cada día más popular. Vaadin está pensado para que los programadores Java puedan construir aplicaciones web RIA con una notable productividad. Vaadin es Open Source y extiende GWT. Nunca lo he probado, pero le tengo muchas ganas. Colegas de trabajo que lo conocen me dicen que la versión 7 trae un importante cambio en la forma de construir aplicaciones. Quizá sea momento de que lo pruebe. Ésta es la torta que la gente de Vaadin hizo para celebrar su nueva y flamante release.
  • PrimeUI: Siguiendo con el mundo de las RIA, esta semana, gracias a este tutorial de Adictos al Trabajo, me enteré de que hay un proyecto bastante interesante que es un derivado de PrimeFaces. PrimeFaces es una comunidad que se dedica a hacer componentes JSF que usan mucho Ajax (competidor de RichFaces, OpenFaces o ADF Faces). Por supuesto, todos estos componentes están programados en JavaScript. PrimeUI son los componentes JavaScript publicados como librería para que puedan ser utilizados directamente en una página, sin tener que pasar por tags JSF. Dado que los componentes usan JQuery, es fácil incorporarlos a una página para un programador JavaScript. Este enfoque me resulta en extremo interesante, ya que una empresa podría tener desarrollos Java encarados con JSF y usar PrimeFaces, y otros desarrollos JavaScript que utilicen componentes PrimeUI, y no diferir demasiado en su Look & Feel.
  • Actualización de OpenShift: Tomcat 7 y JBoss EAP 6.0.1: Ustedes saben que la idea de OpenShift me gusta mucho. Si bien he metido poca mano aún, vamos, ¡es una PaaS basada en JBoss! En el link de JavaHispano no sólo está la noticia, también pueden encontrar los dos podcast en que JavaHispano entrevista a Juan Nocera, Product Manager de OpenShift.
  • Nuevo Podcast de Ideas Ágiles sobre TDD: Otra cosa que me gusta: los podcast de Ideas Ágiles. Nunca he implementado TDD hasta ahora, pero después de escuchar el podcast me dan muchas ganas de probar.
  • Los ins y los outs de la Inmutabilidad: Para cerrar, un post sobre Inmutabilidad en Java, un tema que me gusta mucho y del cual hace mucho que tengo ganas de hacer mi propio artículo. Quizá este año efectivamente lo haga.
Eso es todo por hoy. Espero que disfruten el Carnaval. ¡Nos vemos la próxima!

martes, 5 de febrero de 2013

Principios de Diseño

Hace poco terminé de leer el excelente y altamente recomendable libro de Cecilio Álvarez Caules sobre Arquitectura Java. El libro es muy interesante porque explica cómo, a partir de una sucesión de refactorizaciones guiadas por el sentido común, una aplicación bien simple de gestión de libros de una biblioteca evoluciona desde una arquitectura de una única capa, con JSP y JDBC directo a una base MySQL, hasta una arquitectura clásica Java EE de tres capas, implementada con JSF, Spring y JPA.

En realidad ese "sentido común" son más bien los Principios de Ingeniería, o como a mí me gusta llamarlos: Principios de Diseño, y esto es de lo que quiero hablar en este post.

Los principios a los que el libro hace mención son los cinco de SOLID (de los cuales ya hablé una vez) y tres más que son ampliamente conocidos. Me voy a tomar el atrevimiento de copiar las definiciones del libro (agregando algunas anotaciones mías) así los entusiasmo para leerlo:
  • DRY (Don't Repeat YourSelf): implica que cualquier funcionalidad existente en un programa debe existir de forma única en él, o lo que es lo mismo, no debemos tener bloques de código repetidos. (Nota mental: cortarme la mano antes de abusar del copy & paste.)
  • SRP (Simple Responsibility Principle): toda clase o componente debe tener una única responsabilidad y todas sus funciones deben orientarse hacia ésta. Otra forma de enfocarlo es: una clase, al tener una única responsabilidad, sólo debe ser alterada a través de un cambio en dicha responsabilidad.
  • OCP (Open Closed Principle): todo código desarrollado para una aplicación debe estar cerrado a las modificaciones y abierto a la extensibilidad. Expresado de otra manera: debemos poder añadir nueva funcionalidad a la aplicación sin tener que alterar el código ya construido. (En la Orientación a Objetos el mecanismo por excelencia para lograr esto es la herencia, y esto nos lleva al siguiente principio que es...)
  • LSP (Liskov Substitution Principle): se menciona en el libro pero no se explica. Este principio está muy relacionado con OCP, y también con la buena práctica de siempre trabajar contra interfaces en lugar de implementaciones (interfaces o la clase más alta de una jerarquía). Una porción de código, digamos un método, debería conocer la clase padre, y funcionar de modo correcto si como input recibe una clase hija. Así, ese método estará cerrado ante modificaciones pero abierto a la extensibilidad, ya que podremos cambiar comportamiento simplemente creando una nueva clase hija y sobreescribiendo algún comportamiento de la misma.
  • IOC (Inversion of Control): consiste en que el control de la construcción de los objetos no recae directamente en el desarrollador a través del uso del operador new, sino que es otra clase o conjunto de clases (habitualmente llamado Contenedor) las que se encargan de construir los objetos que necesitamos.
  • DIP (Dependency Injection Principle): las dependencias que una clase tiene no deben ser asignadas por ella misma sino por un agente externo (a menudo llamado Contenedor). Podemos lograr Inversión de Control con un Factory, por ejemplo, pero si queremos Inyección de Dependencia tendremos que usar Reflection o algún framework como Spring o CDI.
  • COC (Convention Over Configuration): define que, antes de abordar el desarrollo, un programador puede declarar una serie de convenciones que le permiten asumir una configuración por defecto del sistema.
  • ISP (Interface Segregation Principle): una clase cliente A que tiene una dependencia con la clase B no debe verse forzada a depender de métodos de la clase B que no vaya a usar jamás.
Por último, Caules se hace una pregunta muy importante: ¿Qué es lo más importante a la hora de diseñar una aplicación? ¿Los Frameworks que se van a utilizar, los Patrones de Diseño, o los Principios de Ingeniería (SOLID + DRY + IOC + COC)?

La respuesta que da se puede vislumbrar en el siguiente diagrama:


Los frameworks están construidos apoyándose en distintos Patrones de Diseño y un conocimiento sólido de éstos nos permitirá entender de una forma más natural el funcionamiento de los frameworks. Podemos dar como ejemplos el patrón Data Mapper de Martin Fowler, en el cual se basan todos los ORMs como JPA, o Repository usado por Spring para anotar los DAOs, o Front Controller usado por muchos frameworks MVC como JSF o Struts, y así podría seguir todo el día.

Si seguimos profundizando en este análisis, pronto nos daremos cuenta de que los Patrones de Diseño no salen de la mente retorcida de diseñadores y arquitectos porque sí, sino que nacen para satisfacer Principios básicos de Ingeniería. Así, el patrón MVC aparece una vez que se dividen las responsabilidades de Modelo, Vista y Controlador usando el principio SPR, el patrón Front Controller surge cuando se quiere obtener la propiedad OCP en una capa de presentación, o el patrón Template queriendo aplicar DRY en una jerarquía de clases concreta.

Lo más importante para los arquitectos, concluye Caules, es conocer estos principios de diseño de software ya que nos facilitará sobremanera el entender por qué un código se ha de construir de una manera u otra.