Este documento resume el estado actual de las tecnologías y metodologías utilizadas en el desarrollo de software. Describe brevemente las herramientas, lenguajes, frameworks y metodologías ágiles más comunes como Spring, Hibernate, JUnit, Scrum y Extreme Programming. También menciona alternativas a estas tecnologías y buenas y malas prácticas en el desarrollo de software.

1. { El estado del Arte }
“conociendo nuestro FUA interior”.
José Bovet Derpich
08/08/2011

2. Agenda
 Estado del arte
 De las buenas prácticas

3. El estado del arte
 Que hay en el día a día.
 ¿qué, y con que lo hacemos?
 Tecnologías que usamos.
 IDES
 Servidores y contenedores webs
 No reinventamos la rueda
 Nuestra piedra angular
 Spring e IOC
 Nuestras Aplicaciones
 Componentes en FO - BO

4. Nuestro día a día

5. ¿qué hacemos?
 Programamos
 Pruebas
 Análisis de requerimientos
 Modelado
 Diseño
 Administración de Proyectos
 Gestión del cambio
 Comprar compulsivamente cupones, hacer free shipping en
dealxtream.com, entre otras.

6. Y como…
 Ocupando herramientas adecuadas
 No reinventando la rueda
 Reutilizando
 Arquitecturas basadas en
componentes
 Implementando patrones de diseño
e integración.
 Testeando

7. Tecnologías que usamos.
 Lenguajes

8.  IDES

9.  Servidores de aplicaciones y Contenedores
Web

10. S.O

11.  No reinventamos la rueda.
CXFJAX-WS
ORM
WebServices
JavaScript
Vista
Test
Tareas y Builders
Utilitarios, loggers, etc
SCM
SearchEngine

12.  Nuestra piedra angular

13. pero… ¿que es Spring?
 “Spring es una tecnología dedicada para permitir
construir aplicaciones usando POJO’s…” Rod
Johnson
 Spring es un framework que resuelve mucho
problemas comunes en el desarrollo de
aplicaciones en Java(SDK,EE)

14. pero…¿porqué Spring?
 Porque reduce la complejidad de desarrollo JEE
 Simplificar sin sacrificar poder.
 Facilitar mejores practicas, que de otra manera son
difíciles seguir.
 No esta enfocado a una parte especifica de una
aplicación.
 Desarrollar aplicaciones usando POJO’s
 Impacto mínimo. Principio de la filosofía de Spring.
 Porque nace de la experiencia práctica de muchos
desarrolladores en todo el mundo

15. El poder de POJO

16.  Spring Framework y sus sabores
 Spring Security (ex
ACEGI)
 Spring AOP
 Spring MVC
 Spring Web Flow
 Spring JDBC
 Spring Transaction
 Spring Scheduling
 Spring WebServices
 Spring Test

17. Integramos Spring con…
 ORM: Hibernate, JPA, TopLink, JDO, OJB,Ibatis.
 DAO: Manejo de transacciones a través de
 AOP + IBATIS
 JEE: JMX, JMS, JCA, Remoting, EJBs, Email
 WEB: Spring Web
MVC, Struts,Tapestry, JSF, JSP, RIA, Velocity, Fr
eeMaker, ExtJs, Jasper Report, Portlet MVC
 AOP: AspectJ

18. Donde lo usamos…

19. En todos los escenarios…

20. Con otros frameworks

21. En remoting

22. Nuestras Aplicaciones
 Front Oficce
 Back Office

23. Tecnologías usadas
Nombre Versión usada Última versión
Java 1.5 – 1.6 7(Aún inestable)
Tomcat 5.5 – 6.0 7.0.20
Spring/MVC/WebFlow/T
est
2.0 – 2.5 3.0.5
Spring Tool Suite 2.3 -2.5 2.7.1
Spring Security 2.0.3 3.0.5
IBATIS 2.3.4.7 Ya no
existe
3.0.6
Mybatis
Axis 1.4 1.5.5
Velocity 1.6.4 - 1.5 1.7
JUnit 4.4 4.9
JQuery 1.4 – 1.5 1.6.2
ExtJs 3.2.0 3.4 / 4.0 Alpha

24. Alternativas
 Spring:
 Ibatis:
 Axis:
 Junit: TestNG Jtiger EasyMock Mockito
 STS:
 JQuery-Extjs: GWT - Prototype – Dojo -
Script.aculo.us
JDO JPA TopLink QuickDB DataNucleus
CXFJAX-WS spring
ws
REST

25. Malas Prácticas

26. “Todo en uno”
No existen librerías
especificas
No se tiene información del
componente.
¿Qué hace cada jar?

27. “La redundancia, a veces, no es
buena…”
Duplicidad en los componentes
Saludos
java.lang.NoClassDefFoundError
Cual es la que vale?
JUnit en el deploy?

28. “El orden de mi
desorden…”
Archivos de configuración por
todos lados
No existe agrupación por
componente o funcionalidad
Mezclar peras con manzanas.
!Solo necesito modificar un
Bean!

29. “Abuso de las librerías.”
Desconozco lo que ya esta
hecho.
Un caos!

30. “No tenemos un estándar”
“Extiendo y también uso
anotaciones para mis
test”

31. “No tenemos un estándar”
“¿Se que clases necesito ocupar?”
• Controller
– AbstractController
• MultiActionController
• BaseCommandController
– AbstractCommandController
– AbstractFormController
» SimpleFormController
» AbstractWizardFormControll
er
– ThrowawayController
– ParameterizableViewController

32. De las buenas prácticas
“Producer good software is hard”

33. Automatizar pruebas
 Probar funcionalidades del software durante el
desarrollo.
 Detección de errores en etapas tempranas y no al
final del desarrollo.
 Obtener métricas, informes y estadísticas.
 Imponen restricciones de diseño del software para
que sea comprobable.
 Evita el acoplamiento de diferentes componentes.
 Mediantes herramientas y técnicas como CI.

34. Integración Continua
“Practica de desarrollo software donde los miembros de un
equipo integran su trabajo frecuentemente, por lo menos
diariamente y llegando a múltiples integraciones al día.
Cada integración se comprueba por una construcción
automatizada para detectar errores de integración lo antes
posible. Muchos equipos encuentran esta aproximación como
una forma de reducir significativamente problemas de
integración y que permite desarrollar cohesivamente software de
forma más rápida.”
Martin Fowler
”

35. Enfoque de la CI
 Automatizar tareas de building
 Generar informes y métricas de tests
 Proveer información útil para realimentar el proceso de
desarrollo (feedback)
 Identificar problemas o errores en la integración del código
 Hacer el proceso de integración transparente al equipo de
desarrollo
 Establecer uniformidad en la programación del equipo
 Mantener actualizado y centralizado el código de
desarrollo

36. Una mirada a CI

37. Herramientas

40. Control de versiones

41. ventajas del control de
versiones
 Proveer entornos distribuidos y/o centralizados a los
desarrolladores.
 Tener un control exacto sobre cual es la última versión del
código, y quién y cuando la ha cargado.
 Poder comparar versiones, viendo cuales han sido los
cambios realizados.
 Regresar atrás (a una versión anterior) cuando lo que
hemos desarrollado no nos ha dado los resultados
esperados.
 Crear distintas ramas del proyecto. Si llegado a un punto
se hace necesario hacer dos aplicaciones con distintas
funcionalidades, pero con cosas en común, se pueden
separar en dos ramas.

42. Herramientas Control
Versiones
 Centralizados
 Distribuidos

43. Administración del Proyecto
 definir un ciclo de vida básico del proyecto sobre
el que se pueden ir ejecutando ciertas tareas
asociadas.
 Facilitar la gestión de las dependencias a partir
de repositorios remotos de librerías, incluyendo
las dependencias transitivas.
 Permite la generación de todo un site de
documentación del proyecto (javadoc, informes
de calidad, etc.)
 Realiza la generación y publicación de releases.

44. Herramientas

45. Pero aún faltan
 Issue tracker
 Virtualización
 Testing Tools

46. Algunas mas…
 Reutilizar
 Automatizar la compilación e
integración
 Mantener un repositorio de
código
 Hacer tus propios tests
 Commits diarios
 Compilar rápida y ágilmente
 Testar en clon de
producción, desarrollo, QA, etc
.
 Resultados accesibles por
parte de todos
 Versionar los componentes.

47. Sobre las metodologías

48. Enfoques
 Existen variados…
 Cascada
 Basas en prototipos
 Incremental o evolutivo
 Espiral
 OO
 Cascada con sub-proyectos
 Entrega por etapas

49. Metodologías
 De los 90
 RAD
 OOP
 DSDM
 SCRUM
 RUP
 Desde hace 12 años
 XP
 EUP
 DDD
 TDD
 FDD
 BDD

50. Algo sobre metodologías
ágiles.

51. Agilismo
 Empezó por el manifiesto Agil en Febrero 2001
 Surge por la necesidad de mejores métodos
para construir software
 La construcción de software DEBE considerar
diversos tipos de pruebas

52. Principios
 Individuals and interactions over processes and
tools
 Working software over comprehensive
documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

54. Métodos Agiles
 Lean
 SCRUM
 Crystal Clear
 Extreme Programming

55. Enfoque ágil...
 Software que funciona-Satisfacción del cliente
 Adaptar el proceso continuamente
 Comunicación cara a cara
 A veces dificil
 Excelencia técnica
 Simplicidad
 Auto organización

56. Lean Software
Development

57. Eliminar desperdicio
 Burocracia
 Comunicación Interna lenta
 Requerimientos no definidos o nebulosos
 Código innecesario

58. Extreme Programming
(XP)
 Conjunto de practicas sencillas
 Es difícil su implementación si no hay
compromiso
 Su objetivo es mejorar la calidad del software y
responder a los cambios en los requerimientos

59. Practicas en XP-FeedBack
 Retroalimentación
 Programación en pares
 Juego de planeación
 Test Driven Development
 Esto es diseño mas que pruebas

60. Practicas en XP-Proceso
Continuo
 Procesos continuo
 Integración continua
 Refactoring
 ¿Rewrite?
 Liberaciones pequeñas

61. Practicas en XP-
Codificación
 Codificación
 Pruebas de unidad
 Optimizar el código al final
 No horas extra (40 horas a la semana debe ser
suficiente)

62. Practicas en XP-Pruebas
 Pruebas
 Pruebas de unidad para todo
 Pruebas de integración
 Deben funcionar todas las pruebas antes de liberar
 Si surge un error (bug), deben escribirse las pruebas para
replicarlo. Un bug es una prueba que olvidamos escribir

63. Pruebas de unidad
 Se prueban los componentes aislados
 Generalmente se usan Mocks o Stubs
 Se usan verificaciones “asserts” para probar
 Son confundidas con Pruebas de integración
 Pruebas de caja blanca

64. Pruebas de integración
 Sirven para probar los componentes
involucrados en un flujo
 Validan el trabajo de varios desarrolladores
 Pruebas de caja negra
 Pueden ser automatizados, simulan la
interacción con el usuario

65. Impacto de las pruebas
 El tener una buena batería de pruebas, nos
permite entre otras cosas:
 Validar nuevos requirimientos
 Medir el impacto de los refactorings
 Documenta el proyecto
 Permite mejorar el diseño

66. Faltan mas pruebas¡¡
 Pruebas de Stress
 Pruebas de Performance
 Pruebas de Integración de Sistema
 Pruebas de Aceptacion
 Pruebas de Sistema
 Pruebas no funcionales
 Pruebas Funcionales

67. Notificación visible

68. Visual management

69. Atlasian
https://jira.springsource.org/secure/VersionBoard
.jspa
https://jira.springsource.org/browse/SPR
https://jira.springsource.org/secure/IssueNavigat
or.jspa?

70. I+D

71. El presente de Java
 Lenguaje != plataforma.
 Lenguaje=SDK
 Plataforma = JVM

72. JVM como plataforma
 Groovy
 Scala
 Jruby
 Jython
 Clojure

73. Mediante ByteCode

74.  Lenguaje interpretado
 Multiplataforma
 Orientado a Objetos
 Sintaxis clara
 Funciones y librerias
 Gran comunidad detrás

75.  Nace a finales de 1997
 Python en Java
 Identyico a python 2.2
 Al igual que Python, Jython es dinámico
 Mas o menos maduro para el funcionamiento en
JVM

76. Ejemplo Jython
Ejecución

77.  Lenguaje de proposito general, dinámico, orientado a
objetos
 Es funcional, imperativo y reflectivo
 Tipado dinámico
 Multiplataforma
 Introspección, metaprogramación
 Soporta alteración de objetos en tiempo de
ejecución
 Venia por Java

78.  10 años de desarrollo
 Compatible con ruby 1.8.7
 Puede correr de manera interpretada.
 Implementación 100% Java
 Al igual que jython, se han tenido que hacer
arreglos para que corra en la JVM

79. Ejemplo JRuby

80.  Empieza su desarrollo 2001
 Es orientado a objetos y funcional
 Significa “Scalable Language”
 El compilador genera byte code
 Diseñado para vivir en la JVM y otros entornos
como .NET
 Pensado para concurrencia.

81. Ejemplo Scala

82. Alrededor de Scala
 LIFT, framework web para hacer sistemas de alta
concurrencia.
 AKKA, plataforma para construir aplicaciones
orientadas a eventos, escalables, y tolerantes a
fallos.

83.  Aparece en 2003.
 Groovy es un lenguaje dinámico, orientado a objetos, muy
íntimamente ligado a Java.
 Diseñado para “robarse” cosas buenas de Python y Ruby
 EL 99% del código Java existente puede ser compilado mediante
groovy.
 El 100% del código Groovy es convertido en bytecode Java.
 Gran comunidad detrás
 Varios proyectos alrededor
 Soporte de herrmientas Eclipse, NetBeans, IntelliJ

84. ¡Azúcar sintáctica!
 Listas
def list = [77,'ABC',new Date(), x=15, 'abcdefg'[ 1, 3, 5, 6 ] ]
[77, ABC, Thu Aug 11 12:47:09 CLT 2011, 15, bdfg]
 Mapas
def map= ['id':'FX-11', 'name':’Pepe', 'no':1234, 99:'Y']
 Rangos
def toUp = 5..99
def toDown = 100..0
 Assignation multiple:
def (x,y) = [45,-35]
 Return Opcional

85. Herramientas sobre Groovy
 Testing
 Spock
 GMock
 Construcción
 Gradle
 Gant
 Framework
 Grails = Web
 Griffon = Swing
 Gaelyk = Web

86.  ¿Qué es Grails?
 Plataforma para desarrollo agil en web
 Framework mvc full-stack
 Convención sobre configuración.
 Corre y se integra con la JVM
 Desarrollo de aplicaciones con groovy y java
 Orientado a objeto
 Dinámico
 Sintaxis Familiar
 Opensource

87. Grails: La plataforma

88.  Ventajas y Caracteristicas
 “The real” ORM, con cero configuración
 Dependency Injection
 Manejador de transacciones
 Internacionalización
 Web Flow
 Tag libraries
 Caching
 Layouts
 Ajax
 Servidor no necesita reiniciar(most cases)
 Desarrollo de pruebas en caliente
 Unit Testing
 Integration Testing
 Functional Testing

89. DEMO
cvs: Investigacion/JFinder

90. Resumen
 Lo que nos ha funcionado…
 Lo que nos gusta usar para desarrollar …
 Lo que nos ha hecho mas productivos…
 Lo que nos puede dar control sobre el proceso de
desarrollo…
 Lo que nos puede permitir visualizar el desarrollo…
 Lo que nos gustaría implementar…
 Lo que necesitamos para mejorar….

91. Gracias!