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
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
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
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
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”
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
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.
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.
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.
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
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
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
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
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
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
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.
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
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
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
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….